Service Oriented Architecture is a phylosophy on how business should be represented in IT and the approach that is taken to piece together business systems. Web Services is a way of providing access to capability which alows high levels of interoperability between different environments and masks the underlying implementation if required.

The reason they are synonimous with one another is the requirement to interoperate between different systems and not ending up with a complex integration problem. The other aspect of web services relevent to SOA is around the governance and management of services. The desciption of the service can be declared as a WSDL when using web services and all services can be managed centrally using this declaration which provides a strong SOA governance capability.

SOA can be implmented without web services but that does require a standard declaration technique and a standard way to deal with the interoperability between different systems. Web Services solves those problems and allows flexibilty of transport and location and can provide additional quality of service management within the request.

In summary SOA and web services makes sense but is not a pre-requisite.

Ritchie Hale

Designing for performance does not make the development effort more, it may make it less as we have to think about what we do before we do it. Performance after the fact always adds time and cost to development, performance as a design phylosophy rarely does.

In designing for performance the two key characteristics we look for are coupling and cohesion. Coupling is how components relate to one another, high coupling is bad and low coupling is good and this has a major impact on the applications ability to run fast and the amount of CPU consumed by the application. Cohesion is how well the elements within a component relate to one another. High cohesion, i.e. the elements within the component are highly related, works well and is good, low cohesion is bad. Again low cohesion affects the ability of the component to perform.

The protection of the thread of execution is another key. Anything that does not provide value to the consumer but is required to maintain the integrity of the system such a logging, needs to be removed from the thread of execution as close to the thread as possible. What I mean by that, is the thread should not be waiting for a log event to be logged to the database, the log event should be handed off to an asynchronous capability and the logging done in its own time without the thread of execution being interuppted or waiting for the log event to complete.

I will stress, I do not advocate “spinning up threads” in the J2EE environment as this is contrary to the specification. I do advocate using some of the asynchronous capabilities such as messaging – fire and forget – based principals.

If you do nothing else but concern yourself with the above and model the dynamic behaviour of the components and their interactions, this itself will save you time and money in the long term and provide you with better performance and lower CPU consumption – the classic doing more with less.

 Ritchie Hale

So what is state? State is the awareness that an application has of what the previous call to itself was about. It is an awareness that the application has of each and every request that was passed to it. Any long running process has state that goes beyond a request.

An example of state in an process is the mortgage application process. This application changes state as it moves through the approval and funding process and each step must be aware of the steps that were completed before as for example  funding is based on approval, so without approval there is no funding step.

The state within an application need to be carefully positioned. Application complexity goes up dramatically when state is introduced and therefore impacts delivery. All attempts should be made to make your applications completely stateless and I have found over the years there are only 2 exceptions to this.

The first is the converstional state that exists between the client and the application. The application needs to go from one page to the next and potentially go back as well, this is particlularly true of browser based applications. The state of the client and application interaction is called the session and various pieces of information are stored in the session so the application is aware of what the user has just done.

The second state management requirement is that of process state. This is like the mortgage example above, as a process is run, the state is carried from application request to application request and needs to be managed. This state management should not be placed and managed within the application, or services it should be managed within state management tools such as process server technologies.

It is the misplacement of state within an application that creates significant complexity issues, but when state is kept out of the application and only exists within the process server capability, the application simpicity increases and delivery targets can be met.

So your target in any design is to have a stateless application, with state only existing in 2 places, the first is the session, the second is within the process serve technology you are using and nowhere else.

Ritchie Hale

So what is flexibility, well it depends on who you ask. The CEO would say it is the ability to make his business react swiftly to changing market conditions, the CIO would say it is the ability of his systems to react to changes in the business. Both are similair but the motivation for change is different; one the market, the other the business.

So we talk about this alot but what does it actually look like. Some poeple say it is de-coupling, some say it is re-use, I would suggest that it is both. The challange in both of these characteritics is they can both be highly destructive as well as constructive.

Lets look at the negative first. If we build a system where we focus on re-use, we break down the components into small re-useable elements, which sounds great, but as we scale the system, this characteristic creates performance problems as the inter component communication gets out of control and becomes such a large overhead as to be unuseable. When de-coupling is taken to the nth degree, the consumer and provider know nothing about one another and often the format of the data is converted into an imtermediate format that just adds overhead to the call between these components. This may work on a low volume system, but as volume increases this format change becomes an extreme overhead ad slows down the system.

What this illustrates is that the techniques on their own and when used excessively do not deliver flexibility, however when used together and within certain constraints do offer flexibility as a side effect of their use.

So when delivering the flexibility characteritics we must balance off the use of de-coupling and re-use against performance and maintainability to achieve the outcome we seek.

 Ritchie Hale

The military have the same problem and have solved it by structuring how orders are given to troops and I will use this as a comparison to illustrate how this can be done.

Military orders are structured using the following acronym SMEAC, Situation, Mission, Execution, Administration and Control.

The Situation is provided “3 Up”. That means the soldiers are informed about the commanders intent three levels up; what is the commanders view of the world 3 layers of management above where your manager is now. This mechanism provides the soldier on the ground with a very high level view of where what they are doing fits in to the bigger picture.

So this would mean that a developer on the ground would be provided with not only the technical element of the project, the functional business view, the divisional business view and probably the CEO’s view of the project. This then allows the developer to make decisions with a high level of awareness on where what he is doing fits into the bigger picture and therefore be more aware of the impact his decision making may have on the overall project.

This SMEAC technique works for the military and can also work for IT projects and help the people making the decisions be more aware of the impact their decisions will have on the overall project as they understand the context they are in.

Ritchie Hale

The implementation of a central control model allows all the decisions that are made at a technical level to be firstly congruent, i.e. all the decisions support a single outcome and eliminate large amounts of technical problems and costs, the second is the technical implementation of the project stays aligned with the business outcome being sought.

The implementation of this is a deeply contraversial issue as it means effectively dissempowering a large number of people. It means passing complete technical control of the project to just a few if not just one person. This power is absolute and a high level of trust is required to make this work. It forces technical decisions such as product selection to be made by technicians not business people, it forces this individual or small team to be responsible for the outcome the business needs.

The biggest challange for the individual who is in this role is the requirements for strong leadership as well as strong technical skills, a rare combination in itself. But with the correct development or hiring these individuals, companies can find the right or develop the right people.

This model has the largest impact in a project’s success and should be considered critical within any organisation.

Ritchie Hale

Developers are empowered to make decisions because nobody else takes responsibility for making the decision at the higher level. This problem starts with management’s unwillingness to get highly involved in IT projects, to business being unwilling to get highly involved, to architecture being seen as something abstract and a lack of willingness by developers to accept having somebody checking over their shoulder all the time and an unwillingness for the design/architects to drive the agenda.

So developers make decisions but they only make decisions with the information they have available and not with the bigger piture in mind.

If you are going to delegate responsibility then you need to provide the executive vision at some level of detail so that the developer has enough information to make decisions that are congruent with other decisions being made on the project.

Developer also don’t find their work being evaluated or critiqued. This is an area where there is not enough attention. The assumption is always the developer understands what he has to do, this is rarely the case. In the vast number of projects I have worked on less than 5% of the people involved really understand the technology they are working, the rest can do the activity, but the quality and true understanding of what they have to do is so limiting to be fightenting.

So executives, the business and architects need to get more involved and ensure that are accountable and responsible for the outcome and don’t just expect the outcome without checking what people are doing.

Ritchie Hale

The really important piece, which provides us with the flexbility in the system is the answer to the question how do these components actually relate to one another when they are doing what they are suppossed to do.

The answer to this question explans how the system is actually going to behave when it is running.

You can design sysems using the static model only, but you do not uncover performance and maintentnance issues that the sytem will have when it is running. Performance issues can surface with only 2 or 3 users on the system so should never be discounted and maintenance is a part of life and so needs to be understood.

I am an advocate of designing a system from a dynamic point of view using interaction diagrams that show how the system will behave when it is running as well as showing what bits exist and what they do.

For success in systems design, the dynamic view is critical as it uncovers those issues which are going to cost you the most if they are not solved during design.

 Ritchie Hale

I believe developers should be apply common coding patterns to common problems and the creativity should be limited to a select few. These common patterns should include object structure, object relationship and allowable and disallowable code.

Developers should be reproducing what the architect and core design team define. The only creativity should be in the code filling the business methods themselves, and even this is limited to only certain code.

Why this draconian constraint, developers do not fully understand the impact their code has in a high performance, high volume, multi-threaded environment. They do not see what happens with the code in-flight and since most developers do not understand how to produce designs and analyse the dynamic behaviour of their design, they should not be asked to operate in this space.

It is the responsibility of the core team to identify these behaviours and confirm if they work in the bigger context of what they are trying to do, developers should then be tasked with replicating this behaviour.

I will add one point, this does not mean everthing is a nail just because I have a hammer, so one design/solution does not fit everything but in most cases it will cover at least 60 to 70% of the outcome.

Ritchie Hale

I have discovered a very simple technique for increasing your success rate using a proven life skill, find out how it has been done before and copy that.

So how does this apply to our projects.

Learn how to solve the problem using the best members of the team and then get everybody else to copy what they did and apply the same technique. What this effectively does is remove the creative nature of development from the many and place it in the hands of the few and allow the many to just copy the solution again and again.

Suprisingly enough the same input will give the same output and therefore the same outcome. This means that with a success receipe as the input the outcome will be consistent and so therefore will the result.

Simple but elegant

Ritchie Hale