Architecting Service-oriented Technologies

In his new article, "Architecting service-oriented technologies" Philip Wik outlines three main hurdles creating solutions based on service-oriented technologies (SOT):

• Complexity...

  - How can we model complexity at the right level of detail and abstraction?

• Communication - Design Elements

  - What are the building blocks of STA?

• Execution - Organizing for Success

  - How can we foster velocity and quality in building STA solutions?

According to Wik, the most important thing to remember when dealing with real life problems is that:

... we must accept as a given that there are questions without answers and that a true understanding of any entity will elude us, as there are limits to thoughts and symbols... we must cope with unfathomable unknowns. But in this realm of mystery, we must act. And we do so with the help of frameworks. A framework is a blueprint that lets us envision, plan, develop, test, deploy, and stabilize architectures.

In Wik’s opinion, the two most important frameworks for SOT solution implementation are Open Group Service Integration Maturity Model (OSIMM) and The Open Group Architecture Framework (TOGAF). .

The importance of OSIMM is that it defines a process to create a roadmap for incremental SOA adoption that provides clear business benefits at each stage. It also provides a quantitative model to help evaluate the current and future state of SOA maturity. The value of TOGAF is providing an enterprise architecture framework which helps answering the question: How can we build systems to achieve business goals?

Moving on, Wik introduces two fundamental STA design elements - principles and patterns. According to him:

A principle is an imperative standard... They come from common sense and from our shared humanity. Principles are also a priori propositions, reasonable perhaps but not provable... If we fall short of the principle, the principle remains but so does our failure of that principle.

Regarding the main principles that should guide service technology architecture, Wik uses well-known SOA design principles, including Service Loose Coupling, Standardized Service Contract, Service Autonomy, Service Statelessness, Service Composability, etc. When using these principles, Wik cautions:

It’s a mistake to build an architecture based on an application of principles rather than the principles themselves. The reason for this is that it puts us into a position of chasing or locking in technology rather than driving towards business goals.

When it comes to design patterns, Wik again suggests leveraging widely adopted SOA design patterns.

Finally, for Organizing For Success, Wik suggests leveraging Agile Development for improved accountability and communication that a daily scrum offers, and XP for quality and velocity that pair programming offers. He asserts that those are fundamental as they buttress the higher principles of transparency, communication, quality, and velocity that enable STA success.

Wik concludes his article by saying that:

Developing service technology comes down to simplifying systems to meet enterprise goals and simplifying processes to reach those goals. We don’t disparage the effort it takes to master the tools that can help us craft a STA. But getting to where we want to go to might require that we abandon our old tools. TOGAF, UML, and Agile/XP are invaluable ladders. But there are times when we may need to throw these ladders away to see the world of services rightly.

Despite many interesting ideas presented in his articles, some of the ideas are confusing. First of all it is not clear why Wik abandons the term SOA, replacing it with SOT. While typically this term refers to things like Web Services or Service Component Architecture - technologies that allow easier implementation SOA solution, Wik is using the term interchangeably with SOA. In fact most of the references, principles and patterns in his article are borrowed from SOA. Moreover, a large part of his article is dedicated to business goals and business drivers, which historically was not the main technology driver, which were typically driven by simplification of implementations.

The other problem with title stems from the fact that technology is usually not architected, but rather used. So it is not immediately clear what architecting of technology means.

And finally, although things like Agile, XP and Social Engineering are very important in software development, it is not immediately obvious how these things can be directly applied to the architecture. Despite of numerous publications on the topic, it still remains opened.