I will try to give more insight into PA by using a more formal approach. In the section below I will use the definitions “success state” and “system” a lot. I will define these first:

Success state: P_1 and P_2 and … P_N

P_x (1 <= x <= N) is a predicate, for example: P_1 == (All timesheets employees are submitted), P_2 == (All submitted timesheets are correct).

System: S

S => P_i and P_i+1 and … P_i+m and Q_j and Q_j+1 and … Q_j+n

where P_i and P_i+1 and … P_i+m is a subset of our success state P_1 and P_2 and … P_N

Q_j and Q_j+1 and … Q_j+n are additional predicates, not in our success state.

Instead of system you can also read solution. A system can be an already existing system or something that can be built. To illustrate the difference between traditional strategies and the PA strategy, we will do a step by step construction towards an at first unknown success state T_success. We will start from an empty state T_empty.

Traditional strategy 1:
Step 1) Design new component C_1.
Step 2) Check new state T_1 with customer: is this state the success state? Yes: done, No: proceed.
Step 3) Design new component C_2, connect C_2 to C_1.
Step 4) Check new state T_2 with customer: is this state the success state? Yes: done, No: proceed.
Step 5) Design new component C_3, connect C_3 to C_2 and C_1.
Step 6) Check new state T_3 with customer: is this state the success state? Yes: done, No: proceed.
…

The first strategy starts building new components, one at a time. After each component is finished we check if success state is reached. This is not unlike many hobby projects where you start from scratch and build a component at a time. Once you are happy with result you have reached T_success.

Traditional strategy 2:
Step 1) Apply systems S_q, S_q+1, … , S_q+k (short: S_q’) to T_empty.
Step 2) Check new state T_k’ with customer: is this state the success state? Yes: done, No: proceed.
Step 3) Design new component C_1, add this component to S_q’.
Step 4) Check new state T_k1′ with customer: is this state the success state? Yes: done, No: proceed.
Step 5) Design new component C_2, add this component to S_q+1′.
Step 6) Check new state T_k2′ with customer: is this state the success state? Yes: done, No: proceed.
…

The second strategy starts from a combination of, most likely existing, systems. We then add components one at a time. After each component we check if we have reached the success state. This is a way of building systems which is used often when adding functionality to legacy systems.

Traditional strategy 3:
Step A.1) Apply a permutation of systems S_q, S_q+1, … , S_q+k (short: S_q’) to T_empty.
Step A.2) Check new state T_k’ with customer: is this state a good enough approximation of the success state? Yes: proceed to B.1), No: proceed.
Step A.3) Apply a different permutation of systems S_q, S_q+1, … , S_q+k (short: S_q1′) to T_empty.
Step A.4) Check new state T_k1′ with customer: is this state a good enough approximation of the success state? Yes: proceed to B.1), No: proceed.
Step A.5) Apply a different permutation of systems S_q, S_q+1, … , S_q+k (short: S_q2′) to T_empty.
…
Step B.1) Design new component C_1, add this component to previously found near success system permutation S_q”.
Step B.2) Check new state T_k1” with customer: is this state the success state? Yes: done, No: proceed.
Step B.3) Design new component C_2, add this component to previously found near success system permutation S_q”.
Step B.4) Check new state T_k1” with customer: is this state the success state? Yes: done, No: proceed.
…

The third, somewhat less traditional, starts by finding a good combination of systems. This combination should give a good approximation of the final state the customer wants to achieve. Only then you start adding new components.

Classic PA strategy:
Step A.1) Create a definition of T_success, called T_success’.
Step A.2) Check T_success’ with customer: is this state the success state? Yes: proceed to B.1), No: proceed.
Step A.3) Change the definition of T_success’ resulting in a new definition called T_success1′.
Step A.4) Check T_success1′ with customer: is this state the success state? Yes: proceed to B.1), No: proceed.
…
Step B.1) Directly derive definitions of components C_1, … C_u from best definition T_success”.
Note that C_1, …, C_u => P_1 and P_2 and … P_N must hold.
Step B.2) Match components C_1, … C_u with systems S_q, S_q+1, … , S_q+k.
Step B.3) Choose best matching(s). For these matchings T_success” must be a subset of resulting state T_matching.

PA first creates a state definition as close as possible to the success state. It then reviews and alters this state iteratively. Only when the definition is satisfactory the next phase starts. In this phase component definitions are derived from the success state definition. These component definitions are then matched with systems and the best matchings are chosen. Simplicity is important in PA: we always strive for a correct succes state with minimal size.

Note that the first two traditional strategies have no real focus on the final success state. This means that during development the chosen success state might actually be (a lot) different than the real success state. The biggest difference between the third strategy and the PA strategy is that in PA we disregard existing systems (read: solutions) until a really good success state definition has been found. Also, we extract as much information as we can from the success state definition. We then use this information to define components. Each component definition should represent a part of the success state. These component definitions should be mutually exclusive (i.e. no overlap) and all component definitions together should imply the success state. Next we match the component definitions with all known systems and come up with the best matchings. Classic PA is almost done here. We now compare the best matchings and present them, with cost figures, to the customer.

As mentioned earlier an important aspect of PA is the separation of the success state from any solution. This is important because of the reduced effort needed: anyone involved in the process can just think about the success state and can forget about (existing) systems. Depending on the number of systems this can be a serious advantage.

When there are only few solutions and the customer really doesn’t know what he or she wants, starting from an existing solution and building from that is the way to go. However, when there is one clear success state and many possible (existing) solutions PA will shine.

• [1]: http://www.procesacceleratie.nl/

The idea behind SOA is actually very good. It loosely couples the service and the front-end, thus separating our concerns. The term seperation of concerns (SoC) was first introduced by Edsger Dijkstra about 35 years ago. The Wiki has an interesting qoute on SoC [2]:

“All programming paradigms aid developers in the process of improving separation of concerns. For example, object-oriented programming languages can separate concerns into objects, and a design pattern like MVC can separate content from presentation and data-processing (model) from content. Service-oriented design can separate concerns into services.”

In this context SOA really looks like the next step in programming.

Assuming your company is planning to “go SOA” in near future, what challenges await?
Here are some of the implications that come to mind when using SOA:

• use of external services means higher internet bandwidth usage
• exposure of internal services to external companies means additional security measures become necessary
• using just a single connection to external services means a higher chance of losing messages
• use of possibly badly written external services means additional infrastructure and code measures, such as timeouts, become necessary
• when chaining services complex behaviour can emerge and message based testing tools are highly advised

Using SOA we also have to be more aware of:

• connection failure
• message loss
• service failure

By using a polling mechanism we could improve our awareness, but the transition to a Service Oriented Architecture will still be a step-by-step process [3], where we will learn by doing.

• [0]: http://www.finalist.com/content/19787/hot_or_not_contest_vermaakt_bezoekers_j-fall_
• [1]: http://www.nljug.org/jfall/
• [2]: http://en.wikipedia.org/wiki/Separation_of_concerns
• [3]: http://it.toolbox.com/blogs/the-soa-blog/soa-benefits-challenges-and-risk-mitigation-8075

Subject: “Extreem RAD : Live Web Applicatie Ontwikkeling met Oracle Application Express”
Pro: Roel Hartman
Office: Arnhem, the Netherlands
Date: 28 oktober 2008

Subject: “Standardizing SOA with Oracle’s Application Integration Architecture”
Pro: Adri Greeve
Office: Rotterdam
Date: 13 november 2008

Subject: “Practical Approach to SOA Adoption”
Pro: Edwin van Dis
Office: Amstelveen
Date: 27 november 2008

Register for a Pro4Pro session

On Monday the 20th of October Logica has invited Thomas Erl to speak on the Principles of Service Design and Patterns to transform the most important challenges into a successful realization of a Service Oriented Architecture. Business analyst, functional designers and architects will gain new valuable insights on the modeling of services and supporting architecture.

About Thomas Erl:
Thomas Erl is the world’s top-selling SOA author, Series Editor of the “Prentice Hall Service-Oriented Computing Series from Thomas Erl” (www.soabooks.com), and Editor of The SOA Magazine (www.soamag.com). With over 95,000 copies in print world-wide, his books have become international bestsellers. His most recent titles “SOA Design Patterns” (www.soapatterns.com) and “Web Service Contract Design and Versioning for SOA” were co-authored with a series of industry experts and are being released in the latter half of 2008.

Thomas is also the founder of SOA Systems Inc. (www.soasystems.com), a company specializing in SOA training, certification, and strategic consulting services with a vendor-agnostic focus. For more information, visit www.thomaserl.com.

Program
18.00 uur Welcome & diner
19.00 uur Welcome speach
19.15 uur Thomas Erl – ‘How to overcome the key challenges within SOA’
20.30 uur Drinks

The presentation will be in English of course.

Location
Logica, Prof. W.H. Keesomlaan 14 in Amstelveen

There is more info on the Logica site (in Dutch). You can also register (”aanmeldingsformulier”) there.

• Oracle11g: Advanced PL/SQL
• PL/SQL Programming Concepts: Review
• Designing PL/SQL Code
• Working with Collections
• Using Advanced Interface Methods
• Implementing Fine-Grained Access Control for VPD
• Manipulating Large Objects
• Administering SecureFile LOBs
• Performance and Tuning
• Improving Performance with Caching
• Analyzing PL/SQL Code
• Profiling and Tracing PL/SQL Code
• Safeguarding Your Code Against SQL Injection Attacks

More info: http://education.oracle.com/pls/web_prod-plq-dad/db_pages.getpage?page_id=155

The purpose of this app is to be able to track longrunning contracts with their renewalperiods. One month before you should end the contract (checked on contract enddate) you’ll receive an email. I used Oracle’s DBMS_SCHEDUAL to call the procedure that sends out the email. Also, it has an authentication scheme so that different users can use this online app. Although it’s dutch, everyone can apply now.

 http://apex.oracle.com/pls/otn/f?p=23729

To realize a better workflow the first thing we did was to implement a build-server. We used CruiseControl which suited perfectly for the task, it’s pretty easy to setup and it has a lot of extension points to combine it with all kinds of tools (notifiers, automated tests, software—metrics, version control etc.)

This way we would be able to keep an eye on the status of the code in version control. And we could see when the software ‘breaks’ or works. Well actually we could only see if it would compile, which is not the same

So we installed the automated testing component of CruiseControl and were ‘ready to rock’ the project.

Then again, automated testing only works if you got the right tests. So we decided to use the test-driven approach. First write the test, then the code. This way the build server could tell us, what functionality was thought of, and which part was actually working.

Was this it? Well not really, as the test-driven approach was new for our team it was easy to fall back on the old approach, with the risk of writing more code then was necessary to pass the test. Resulting in untested code.
To pin-down this risk we decided to integrate test-coverage into the build-server, cobertura. This way we would be able to see what code was touched by the test and what code not.

What did we learn with our experiment? First of all it felt like the whole process was going a lot smoother, the test driven approach and tooling made us feel much more confident about the quality of our work. And we realized a pretty high velocity, (the work was done much faster then expected).

This project was for a backend component which I think suits the testdriven approach better then a pure frontend component.

So using this approach(TDD+Cobertura+CruiseControl) for this project helped us achieve a better software engineering process. And it’s very likely that we’ll re-use this approach on our next project.

Cobertura
CruiseControl

We now have one blog with about 45 users and 290 blogposts. The old urls will remain, but both now point to the central merged blog.

For everyone at Logica who hasn’t signed up for a blog account this is your chance, use the contact form to sign up and claim your fame

The reason for the new brand; simplicity, a unified brand replacing the former LogicaCMG, Edinfor, Unilog and WM-data.

On the other hand, it’s just a new name and a new logo which both don’t differ that much from the old LogicaCMG. Apply substring() to LogicaCMG and there you go, firm upgraded.

So goodbye LogicaCMG,

welcome Logica

The LogicaCMG brand, along with the brands of Edinfor, Unilog and WM-data, will transition to the new global brand name in conjunction with the companies preliminary financial results for 2007.

Logica combines the local strengths of all its previous brands with the scale, capability and reach to compete effectively for major opportunities and larger customers. The enlarged group draws on the strength of the local businesses, enhancing its ability to cross-sell propositions and capabilities.

For more information, please look at the full news bulletin on logica.com