Concluding Conference Comments

This is the final of a series of postings on an SOA conference presentation I gave for the Ark Group in Sydney. I seemed to have a great deal of material which probably explains why I ran short of time. The topics I covered with the relevant postings linked were:

• The definition of SOA
• The motivation behind SOA
• Legacy Transition
• My organisation's software stack
• The link between SOA and Enterprise Architecture
• The metadata required for SOA
• SOA and Metadata: Where you can Put It

Of course, there were other speakers as well, and they were all highly competent and informative. I summarized these in an earlier posting.

To wrap this up series up I will go through my conclusions. Firstly, the changes we need to make to support SOA in an organization involve:
• New Components, New Tools, New Skills
• New Application/Service Architecture
• Governance around reuse and business process
• Less emphasis on applications, more governance at the service level
• Focus on interfaces and contracts particularly in the information model
• More Metadata
• Changes to methodology

New Components, New Tools, New Skills
When we talk about changes it is important to understand the baseline from which you are changing. Some organisations will have well developed skills in distributed portal-based applications. My organisation is yet to deploy its portal product and is still developing skills outside of the mainframe environment. We are still building our skills in Unix and Java. We are still putting together our development environment. None of these components, tools or skills are peculiar to SOA. What we have done specifically to implement SOA is to purchase the BEA Weblogic platform and we are looking at ways of changing our development approach. We find we need to quickly ramp up skills in our new environment as well as SOA Development, SOA Testing and management of metadata.

New Application/Service Architecture
There was a critical cell in the Zachman Framework called “Application Architecture”. This could be relabelled “Service Architecture”. It is services that now should be the focus of our attention. This is working at a different granularity.

Governance around reuse and business process
Governance is required around reuse of services and reuse of artefacts. There is more work in the Enterprise Architecture (EA) space than there is for traditional application-centric development. This should be balanced by relatively less work in the solution architecture space. Modelling Business Processes is more important with SOA.

Less emphasis on applications, more governance at the service level
Application Development is more focused on assembly of services and the development of a presentation layer so there is less emphasis on applications themselves. There will need to be governance changes to introduce SOA. There needs to be stronger EA governance. Now you not only have to find an owner and sponsor of an application. You may have to find and owner or sponsor of a service. This may be easier than finding owner for monolithic application in some cases (and in other cases it may not).

Focus on interfaces and contracts particularly in the information model
The modelling of persistent data store won’t change but in addition we need to model the interfaces and contracts between services. This will be required to drive service development.

More Metadata
All this means we have more enterprise metadata. This presents challenges for managing this metadata. This was the subject of an earlier posting.

Changes to methodology
Software development methodology includes more work on interface, contracts and SLAs. The development of testing services presents a challenge. This is because you may have to test without having and application to test it with. You have to test on behalf of applications that may use it but do not exist yet.


I make the following architecture recommendations to facilitate SOA:

• Have an Enterprise Architecture
• Manage the application portfolio
• Drive the enterprise from business processes or from events
• Apply good governance to services and metadata
• Data modeling should include interface/contract design

SOA must be driven from and EA. It is not something that can be put in place for a single application. The benefits of SOA will not accumulate until you have a number of applications completed.

When you build a service you build it for all the applications that potentially use it. Therefore you have to know about these applications. My organisation has a centralised IT department. This helps enable both EA and SOA. A federated model can work but someone still needs a clear picture of the application portfolio and needs to define interfaces and contracts of your services.

Business Processes will drive SOA. This is to ensure the services have meaning to the business and that they can be combined into processes in the same way that business combines its tasks into processes.

The Governance changes in SOA. I’ve talked about the governance of services and the governance of metadata. Both are important for successful SOA.

Once the business process is sorted out the interface and contract between the services must be modelled. This will then drive the development of the services. This information needs to be kept up-to-date and is the key metadata required for reusing the service.


Some of the points brought up at the conference interactive session were true of most software development:

• You need good business sponsorship
• Choose your first SOA projects carefully
• If the business does not see the need then it's not going to work
• Talk to the business in language it understands
• Get executive support of your SOA program

So my concluding recommendation is not to lose sight of what has worked in the past. A lot of what makes conventional development work, will also help make SOA work.