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.

Is Your Enterprise Architecture SOA Compliant?

In August I wrote about the Zachman framework and SOA. This was the basis for a couple more slides at the Ark Group conference on interoperability in which I was a presenter. I have covered material from the presentation in couple for previous postings, "Live up to the Legacy that was Left" and "Why SOA?". I will focus on the main theme of my presentation in this posting which was "Ensuring your Enterprise Architecture is SOA Compliant"

Firstly I would like to point out some work that is being done by the SOA Consortium along these lines. They have announced the Enterprise Architecture 2010 Working Group which is to define the high-level roles and deliverables of the Enterprise Architecture team. There is not much tangible yet from this group as it has just been set up but these people also brought us the SOA practitioners' guides so this could prove a valuable initiative.

At the conference mention in the first paragraph I went over the Zachman Framework as I have done in my earlier posting. One thing I pointed out is that different software development approaches can be described in terms of the framework. I then went on a described my organisations use of the Zachman framework using he colour codes I added to the Zachman grid.

When we talk about top-down approaches conveniently you work from the top row (Scope Row) down to the bottom row (Detailed Representation). Similarly when you work bottom-up you work from the bottom of the framework representation.

Assuming that most good software development is done top-down (and I am subscriber to this approach) you can choose different methodologies depending on the column you choose.

If you drive down the 'Data' column you have a Data Driven Architecture. The Enterprise Information Model in this approach is all important. The other cells of the framework will either support the data column or be influenced by it.

The SOA approach is usually focused on business process and this means it is being driven by the 'Function' column. Software development can be driven from Business Process Modelling and 'Function' column without being SOA.

If we are two focused driving our software development from the 'Network' column we may end up with a siloed application based on organisational locations. This generally software development anti-pattern as modern enterprise software should be independent of location.

Similarly, too much focus on the 'People' column can lead to application focussing around individual or organisational units. This is a very common siloed approach and anti-pattern. More positively a people driven architecture will look at the user experience. This is a common approach for smaller applications to look at screen designs, report layouts and user interaction scenarios that will meet user requirements. For enterprise application though it is important to look at the bigger picture, to question what the organisation is trying to achieve and to model the process from start to finish otherwise the people siloed anti-pattern may result.

If we drive down the 'Time' column we will end up with an Event Driven Architecture (EDA). This is an alternate approach to SOA. We look at events and how they initiate and affect business processes. The 'Function' columns and 'Time' columns can be worked with in tandem to produce and event driven SOA application.

If we work down the 'Motivation' column of the Zachman frame work then we are using a Business Rules Approach. My organisation has not made great use of this framework column. For more information about the Business Rules Approach see http://www.businessrulesgroup.org/ . Also this column is valuable for expert systems and decision management.

With the Zachman framework you do not have to fill every cell. You certainly do not only have one enterprise model in each cell. How you uses the Zachman framework is important. So I will describe how our organisation uses it in terms of the diagram above.

The yellow cells in the above diagram are areas where we have not got any significant documentation.

The green cells contain documentation the business has prepared with out prodding from the IT department. The brown cells are documented by IT but with the interaction of the business.

The top two layers do not change much. These are business level documents. Producing good business process models is more important with SOA. The business process is the key in the SOA process not the application.

The blue is driven by SOA. It starts with your Application Architecture. Distributed Architecture works differently with SOA. You might consider and ESB for instance which will give a different architecture than if you use point-to-point communication. These upper two blue cells drive changes at the more detail level below them.

The pink areas are affected by SOA. Data modelling and Human interface architecture are not radically different but they have to take into account the new architecture.

I will now look at the link between EA and SOA in a different way.

Zapthink has a good article on Zachman and SOA where they use arrows emanating from the Application Architecture cell of the framework. I prefer to represent the influence direction as predominately down representing a top-down approach.

We will start in the 'Data' column again. I do not think the Information Model should be different as a result of SOA. However the Logical Data Model probably should. It should document the interfaces and be able to transform the representation in XML. It should also document the persistent data stores. You now have at least two levels of logical data modelling.

The physical data model and data definition can then be XML, XSD and WSDL. At the same time you have your modelling of persistent data which would be your normal Class Model or ER diagram. This data model would eventually be represented in data dictionaries and database schemas.

We will move across to the 'Function' column now. The Business Process Model should influence your application architecture. Application Architecture should advise you of what services you need and what services to reuse. A service becomes part of the enterprise architecture because it is built for reuse. A new service is also part of a solution architecture. The service has to meet both solution and enterprise needs. Also in this cell is your application stack which supports the service model. The service model then drives the more detailed System Design and the programming.

SOA is a distributed architecture so the lower rows of the 'Network' column takes on increased significance compared with traditional software development approaches. There is more flexibility about where you do your processing. This needs to be built into your Distributed System Architecture.

Business logistics (and particularly whether you are dealing with agencies external to the organisation) will impact your applications architecture. There is a stronger linkage from Application Architecture to Distributed System Architecture because SOA is an enabling technology. It enables you to distribute processing, to look at load balancing and to look at interfaces with other agencies. There is therefore a strong influence on distributed architecture increasing the importance of good architecture in this space.

As with the other columns the influence downward is strong. Your Technology Architecture and Network Architecture needs to be built to cope with the new Distributed Systems Architecture.

Human interface architecture in the 'People' column may change to suit SOA but it does not have to. Some interface technologies work better with SOA. Some ways of interacting with an application work better with SOA but if you want to drive it the other way by specifying your Human Interface Architecture first then this can also work.
Security Architecture gets its own arrow. It is not a logical progression from Presentation Architecture. You may have to do security differently under SOA. You may have to make better use of a standard infrastructure. You may have to use SOA security standards.

SOA for my organisation is business process driven although there is still some bottom up development resulting from services based on mainframe data entities. The focus on reuse and the question for what we already have available to reuse demands some bottom-up consideration.

To be SOA compliant your architecture needs to include:

• Documented business processes,
• Enough bottom-up analysis to reuse of existing services, and
• Data modeling of web service interfaces.

This is in addition to SOA infrastructure and distributed models required the lower levels of your architecture. SOA is an Enterprise Architecture approach. You cannot have an effective SOA unless you have some level of Enterprise Architecture. If you focus on a single solution or application and do not look at the wider needs of the enterprise then you are going to miss the major benefits of SOA.

The business process focus and implications around reuse mean that the business needs to be aware of the SOA approach. It is a change to business practice that the SOA consortium is looking at in its Enterprise Architecture 2010 Working Group.

Live up to the Legacy that was Left …

I presented at a conference last week. After discussing my organisation I provided my definition for SOA and a bit about why my organisation was interested in SOA. I then got onto the topic of this posting which is our legacy transition and in particular how we were going to use SOA to move away from mainframe technologies.

First I presented an age profile of our applications which showed many of our more strategic systems were over 20 years old. Our more integrated systems are written using the IDMS database and ADSO/COBOL. Our more siloed applications are written using the ADABAS database and the NATURAL language.

The mainframe is costly and inflexible environment. It is hard to find developers who know IDMS and the software vendors don’t provide much support for this database technology any more. It is not as agile as a relational database management system. The same is true for our ADABAS applications. It is difficult to find skills. There is at least more of an upgrade path provided by Software AG to move onto newer technologies.

I presented a slide of a plan that was developed more than 4 year ago. It is illustrated here.

The above slide depicts moving from a mainframe environment to a transition stage consisting of an environment where we have some mainframe applications and some J2EE applications accessing mainframe data. The business logic layer is going to be moved off the mainframe leaving applications accessing mainframe data using SQL adapters. The next step is that we move completely off our legacy databases onto relational databases.

This is still the plan. We have made some progress, but progress is slow.

On the right hand side we had n-tier J2EE applications. Now we hope to target a Services Oriented Architecture. This will give us good integration to other agencies and good integration to national bodies. It will assist us to break up the legacy applications and migrate bits of them to newer technologies. It will assist SAPOL to be more agile in its development of software changes.

There is a flaw in this diagram though. This is meant to be a gradual process. We are not going to rewrite a whole suite of applications quickly. We do not have a big budget to break the back of this work. We do not want to risk a huge project that takes years to implement.

Where is the business logic in the old mainframe environment? It is on the mainframe.

Where is the business logic in the co-existence? It is all in the newer technology (blue) areas. What we are finding is that there is so much we have to move to the newer area before we have our first significant application. The step to the transition stage is too big and too risky.

Version 2 of our transition to legacy is illustrated here. Here we have repeated the transition stage and the new environment stage. There is not much difference in the New Environment stage. Except we have encapsulated our business logic and data access in services.

The main difference in the transition stage s that Business Services that are depicted as sitting on the mainframe.

The hope is that we can feasibly wrap up all the mainframe logic in services and reorganise it in custom written business services and combine it with services already written in the new environment.

We would have to make some compromises about what these services might look like, and this would drive a bottom up process in the lower levels of the architecture. But this means that we gradually move our business services over from mainframe to the new environment without having to write huge amounts of business logic at once.

This is done at present using some custom built techniques that duplicates some of the business logic in the mainframe. This is probably not sustainable for rewriting all of the mainframe business logic. Another solution is to encapsulate with more automation. This can be done according to vendors (Neon and iWay). We can encapsulate our existing green screen forms into services without much fuss according the vendors. In actual fact these service adapters cost an arm and a leg and installation and configuration is agony, but that is a familiar story.

The full quote in the title of this posting is

It is up to us to live up to the legacy that was left for us, and to leave a legacy that is worthy of our children and of future generations.

We look forward to making the most of a legacy environment and providing something better for those that follow us.

Reference:
The above quote is from Christine Gregoire, Governor of Washington State, USA in her Inaugural Address, January 12, 2005

Why SOA?

There a couple of things every speaker giving a presentation on SOA feels obliged to do. One is to define SOA and the other is justify it. When I presented last week at an ArkGroup Conference I also did both. The definition I discussed was in my earlier posting. The justification is the subject of this posting.

We do SOA for the following reasons
• Agility
• Reuse
• Assist Transition from Legacy
• Federation
• Extensibility
• Manage Incremental Change
• Better Alignment Between IT and Business Processes.
• Intrinsic Interoperability
• Vendor Diversity
• Support New Technologies
• Reduced the IT Burden

Some of this list comes from a book by Thomas Erl, “Service-Oriented Architecture: Concepts, Technology, and Design,“. 'Manage Incremental Change' and 'Better Alignment…' come from the forward by Scott Dietzen (CTO BEA) of “J2ee Web Services on BEA Weblogic”, a book by Anjali Anagol-Subbarao. The order of the list is from most important to least important and is my own opinion.

Agility and reuse are generally the two main motivations for SOA and they are certainly important to my organisation. The cost of changing a monolithic legacy application is embarrassing. We need to make change at lower cost.

We have a strong need to access its legacy functionality in order to add application functionality delivered in newer technology. This theme was discussed later in the presentation and is covered in a posting on legacy transition.

My organisation is part of a network of agencies that shares one monolithic mainframe database system. This needs to be broken up and moved to a federated model so that we are not bound up in each other’s business decisions. Each agency needs more control over their services. Similarly Australia is a Federation. Each state in Australia has an agency like ours and we all want to share our information. We however also want to retain sovereignty over 'our' data. This is the essence of federation where we share but retain some independence.

Our applications need to be extensible without going back and building from the ground up. This is part of reuse but goes further than that. You reuse what already have and you add to it without compromising the quality of what you already have.

Change has to be incremental. The days of the two year project without showing any output are dying. We need to be able to progress in small, low risk increments. This is also important in my agency because we are unlike to get funds for large changes. We do not only focus on building more code but on changing what we have already built. We should be able to make changes to one part of an application without affect the rest and SOA enables this.

Our applications need to reflect the way our business processes work. SOA promises to deliver better alignment between IT and Business through providing a closer match between the tasks in a business process and software services. I do not believe we will get to the point of business users mapping their business processes and orchestrating their own applications. But if the structure of our systems is aligned to business process then changes should be easier and more compatible with the business.

This slide emphasises that interoperability is not the only game. What is more, it is not point to point interoperability we are concerned with. It is building applications that are intrinsically interoperable (and integrated). The concept of intrinsic operability is explained on a web page by Thomas Erl. SOA provides the promise of systems that provide the ability to interoperate without having to add integration mechanisms. I have an earlier posting that elaborates on interoperablity and integration.

Lastly vendor diversity is important so we can use products and middleware without being tied to a particular vendor. This should therefore help keep costs down and avoid being locked into proprietary systems. SOA also limits the risks of a proprietary product not being supported in the future.

The ability to support new technologies is due to the standards involved in SOA and the loose coupling that means the organisation avoids a huge commitment to presentation and data storage technologes. Thus an SOA will not require a large rewrite to add new presentation mediums (such as mobile computing) to its applications. The SOA can be adapted if the data storage approach changes for some of its services.

Thomas Erl explains that SOA can reduce the IT burden of the organisation. This basically means that in the long the run there is less IT to implement if the organisation is properly reusing services. There is less code, less maintenance required, less support of different applications and in general less IT.

Each organisation will have different motivations for adopting SOA and the priorities will be different. As we go on the journey it is important to keep the reasons in mind and assess occasionally whether you are achieving what you set out to achieve.

Binding and Coupling

From the Doug Kaye, the man who wrote the book on Loose Coupling

Loose coupling is like pornography. Everyone talks about it, but when challenged, few can tell you what it is. For some, it borders on a religion with the attendant fervor one would expect from the newly converted.

When I say he "wrote the book" I mean that literally. There is probably only one book dedicated to this subject and he wrote it.

• Loosely Coupled: The Missing Pieces of Web Services, Doug Kaye ; RDS Press 2003, ISBN 1881378241

I am not surprised it is possible to write a whole book on this. Firstly it is pivotal to SOA and secondly there are so many different aspects to coupling. Today I will discuss binding and Coupling but my postings on coupling probably will not be able finish until I read this book.

Binding is the time when a logical description of an attribute is tied to its physical value. For instance a service address can be bound when the source code is written, when it is compiled or when it is linked into an executable module. This is called ‘early binding’ or ‘build-time binding’. A service address can also be bound to its physical address when the message is sent, or when it is handled by intermediaries. This is called ‘late binding’ or ‘run-time binding’.

Some formats of payload can also be bound at build-time. For instance java objects (and serialized data objects) are bound at build-time. Therefore a receiver will reject a message containing a serialized java object that is not bound to the same physical representation of the object.

Generally in SOA, loosely coupled services are also considered to have all aspects of their messages bound at run-time. Having an address or payload that is bound at build-time reduces the run-time flexibility of these services.

Binding and coupling could be treated as independent dimensions of the separation between services. A build time dependency on a message is so significant however that I will roll it into the coupling dimension. This is appropriate as coupling is a combination of characteristics and not a single dimension anyway. By rolling build time dependency into our types of coupling it also enables us to keep our definition of a service clean without having to comment on binding between services.

This leaves me with another coupling type ‘Build-Time Coupling’ which I will add to my list of coupling types. It is more tightly coupled than most forms of message coupling. This list has been modified in my posting about Aspect Orient Programming and I intend to republish it again after I have made a couple more revisions.
'Build-Time Coupling’ is still a form of Message Coupling so I still include it as part of a service in SOA. It would generally not be considered good to have these dependencies and we would be justified in excluding build-time dependencies from the definition of a service.

It is good practice to pass version information in messages between services. Therefore a message may contain a version number or a build date so that another service can check it and take appropriate action. If a receiving service detects a change in the version of the sending service then this fact might be logged, or the metadata inspected or the message may be rejected. This is not a build time dependency described above. It is another metadata control. Rather than add ‘version coupling’ to a long list of coupling types I will combine the other coupling types that have similar metadata that control the behaviour of the services into ‘Process Control Coupling'.

I hope to revise my own list of Coupling Types shortly but in the meantime click on this link to look at the list developed by the man who wrote the book on coupling.

Footnote:
I have found and extended forum discussion on Passing Serialized Java Objects vs. Web Services . This features and appropriately named J. Cowboy who is railing against those bullies in management who want him to develop Web Services instead of passing (build-time coupled) serialized java objects around his system.

Conference Summary Served with Spaghetti

I presented at a conference “Achieving Interoperability in Systems Architecture” on Wednesday. The occasional get together of architects, managers and developers is valuable. You can grab the odd new insight and find new approaches but it is also good to see others attacking problems in the same way and validating your own approaches.

After the conference I thought I would finish this summary on the aeroplane home. I have always wondered how to spend the time on long flights profitably and I admired a couple of passengers using laptops on my previous flight. Unfortunately as I try to use the laptop in flight I am in a middle seat with no elbow room on either side, and now I am served dinner in middle of the flight. I am juggling my laptop and the worst Spaghetti Bolognaise I have ever tasted. Still, here is the summary.

Josh Graham of Thoughtworks kept time well and came up with the comment “Why should I expect straight lines on my Business Process Model when business is inherently messy.” He also introduced one of our New Zealand guests as coming from the land of the “Wrong White Crowd” which sounds like a political comment and spoonerism wrapped up into one.

Mark Murphy of Tower Aust Ltd advocated we start small with SOA. He quoted IDC showing growth in SOA from $3.5bn in 2005 to $33bn estimated in 2010. Mark looked at some SOA definitions and aptly described the current situation where people build silo applications and then expect IT to join them together. He showed a couple of models from Sun and Microsoft showing SOA models that illustrated logical SOA.

Stephen Smith of Arcbok presented a simple framework for assessing the readiness of an organization for SOA. The framework consisted of assessing an organization on the dimensions of Leadership & Culture, Business, Technology, Knowledge, Funding and Sustainability. Each dimension has a number of questions to ask about an organization to asses its readiness. The sustainability dimension described whether the organization had the appropriate support, operations and governance in place for sustain the SOA. This also could include appropriate operational monitoring, measuring and standards. A readiness assessment tool is about risk management. Beware vendor maturity assessments that are used as tools to sell more services.

Krist Davood of AGL and Sensis has achieved something that everyone in the room envied. He had success justified SOA as an initiative using fairly hard-nosed accounting principles. He had justified SOA because of its ability to avoid periodic failures in the business because of the current way of doing things. He had been able cost these failures and justify the project to introduce SOA into the organization. SOA as a strategy to eliminate risk had been demonstrated to be effective.

Centrelink is a huge SOA operation and it was good to hear from Rob Doughty who is their Applications Architect. I liked his characterization of users as “Human Task Delegates” in relation to workflow applications. It was interesting for me to hear about the legacy system challenges that Centrelink have, but also how their portal work in benefiting other government departments. The focus of the talk was the deployment of a portal product which they will be basing all their systems on. I liked the comment that “Portals bring people and process together”. Rob talked about the challenge of working with various IT groups to deliver on a particular pattern of use in relation to the portal. He advocated the use of an “Integration Competency Centre”.

I then presented on Enterprise Architecture and its links to metadata and SOA. Some of this material is already on my posting on SOA Definitions, SOA Metadata and the Zachman Framework. I will elaborate in a future posting.

John Fisher from the NZ Ministry of Education showed us some great business modelling techniques that had found favour with his users. The technique involved Business Element Models, Business Component Models, Business Role Responsibilities and Business Service Models. The models were focussed on producing requirements for widely federated (eg. For 2,700 schools) SOA systems. He introduced the analogy of using power adapter so could use a drill brought in the UK to explain SOA to users.

Jan McConchie of SA Government ICT Services provided an overview of the challenges that she has to bring together the South Australian Government Services to present a common face to the South Australian citizen. This was interesting because the SA Government has established and Office of the CIO and this is showing the desire to coordinate and rationalise government IT activities. As one of the agencies involved, my organisation will be affected by standardisation and IT governance changes. Jan drew on research by Gartner and Saugutuck Technology to explain what SOA meant to her and discussed some initiatives in place for the SA Government.

Chris Howard was from the State Revenue Office of Victoria. Chris focused on risk and SOA and quoted Gartner, advising that it would take 3-4 years before investments in SOA payed off. He discussed a long term plan for legacy transition which was underpinned by full and frank statements about costs, benefits and risks with his business. Chris endorsed ITIL as an enabler of SOA.

Josh ran an interactive session where we discussed the issues of SOA and getting the business on board. It was never clear what you will find when you "turn over rocks" in the analysis process. We discussed what services to build first. It was not always best to do the low risk, high value project first. In the end it might just be business or legislative imperatives that help you make the decision. It was difficult to decide when to do those cross-cutting "hygiene" services.

George Cascales from Integral Energy discussed how he was implementing SOA in an out-sourced environment. He had a small group of architects and had succeeded in being able to develop new applications quickly using reused services. His group focused on standards and governance rather than the actual development. A set of tools and standards would be given to contract developers to develop the services and applications.

Rajat Chopra, the international speaker from Bell Canada provided a good description of how Bell embraced SOA. It was important for Bell to provide common services to serve its various customer channels for selling telecommunication facilities. Rajat provided us with a number of analogies for explaining SOA to management including Lego blocks, a car factory and diet. With diets, you can latch onto gimmicks but in the end it is lifestyle change that makes the difference. This is the same with SOA.

Alex Jouravlev representing the ACS presented twice. Alex’s first presentation was titled Prepare IT and Business for SOA. He traces the origins of SOA back to 1988. He made the point that our business cases do not really engage the business and we need to strive for simple messages using language the business understands to achieve a ‘mental ownership’. Alex supported the model driven architecture approaches but not for the reasons that they were developed. Business requirements should be developed with referencing any ‘system’ and should be modelled with Visual UML Models. Alex noted that several modelling practices that were usually acknowledged as important were often missed. These include Conceptual Business Modelling, Conceptual Data Modelling, Business Object Modelling and producing an Enterprise Ontology.

Later in the day Alex was able to present a model based on CMMI maturity model in an easy-to-understand fashion with the purpose of moving the SOA objective from IT to the business as an organisation obtains more SOA maturity. Alex was able to give us a realistic view of the limitations that would be expected at each level of maturity and provide an insight into how the role of key players like the Enterprise Architect and Business Analyst would change at the various levels.

Ram Kumar was from OASIS and provided an insight into the work of this organisation that is emersed in creating SOA standards. He discussed his role in developing the Justice Sector Information Interchange standard. This was of special interest to me because of my involvement in this sector. Ram emphasised the importance of XML governance and advocated this for successful SOA.

Josh summarised the conference and he may discuss this on his own blog site. Many themes resonated with me but one stands out as I wrestle with my in-flight dinner. We had slides from at least three of the speakers that showed insanely complicated maps of their existing systems. It seems we are all lumbered with integration spaghetti and our hope is that SOA will resolve this.