Architecting Service-oriented Technologies

| by Boris Lublinsky Follow 1 Followers on Dec 20, 2011. Estimated reading time: 3 minutes |


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.

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Sounds too complicated? by Roopesh Shenoy

IMHO - it sounds more complicated than it needs to be. I always get the feeling that architects use OSIMM or TOGAF or other frameworks for the same reason managers stick with proven technologies like Java - noone gets fired for using them. There are so many better learnings from actual implementations like Amazon's entire AWS infrastructure.

And I have no clue what Scrum is doing in that article.

Re: Sounds too complicated? by Konstantin Ignatyev

The article repeats the same false assumption about IT:

Guiding Principle: “Do it right”
Goals: Innovation and Quality
Strengths: Vision and Discipline

That is true for tiny minority of people in IT, not for majority of IT personnel and people at large. Statistically people are guided by principle of maintaining 'status quo' - keeping themselves in a comfort zone. IT stifle innovation more than business folks because of that. So, attempts to use TOGAF and other frameworks are not only attempts to create a job security but also genuine attempts to create some frameworks of reference to make IT into a respectable profession (like doctors and building architects) that has set of guiding principles that keeps IT folks educated and honest and keep business folks from shooting themselves in a foot by requesting to cut corners and do lots of other foolish things.

Does this article generated by automate software ? by Sake .

Does this article generated by automate software ?

Re: Sounds too complicated? by Boris Lublinsky

Regardless whether I agree with Wik or not, I do believe that IT is a respectable profession, thus I am doing it for 25+ years. And I do believe that usage of the appropriate frameworks is actually a good thing. One of the things that IT is actually suffering is the "I know better" attitude that to often leads to repeating of mistakes that where done 20 years ago all over again under the banner of "new technologies" or "new approaches"

Re: Sounds too complicated? by Konstantin Ignatyev

I will consider IT to be a respectable profession when:
- There are no books "HTML for Dummies" or "C++ in 24 hours" . Have you seen "How to become a surgeon on 24 hours" or "How to architect a skyscraper in a week"?

- Customers routinely dictate how low level implementation or architecture should be;

- IT will be able to provide predictable schedule for 'near standard' applications; Stop spending months on projects which can be completed in a week.

Re: Sounds too complicated? by Roopesh Shenoy

I disagree to some extent here -

- "HTML for Dummies" is similar to the anatomy books that kids get that show them digestive tract or the respiratory system. It takes them one small step towards being a doctor, just as books like these take a novice one small step to being an IT professional.

- I don't understand this second point, but I presume you are saying client intervention is too much. That is the case in almost every industry.

- Most useful software projects are the ones that are creating non-standard applications. Projects that bring disproportionate value compared to the cost - and these are complex and unpredictable in so many ways.

I do agree that even simple projects going wrong is the norm rather than the exception, but that doesn't mean everyone in this business is guilty - there is such a large demand that there are new people coming in all the time, learning all the time. If anything it proves that being good at this is really hard, and hence it is quite a respectable profession.

Of course it doesn't take anything like years of med-school or residency to become a developer. But then it's not really life and death, is it.

Re: Sounds too complicated? by Boris Lublinsky

Roopesh, this is one of the problems.
It does take years to be a good developer and it is life and death sometimes.
The fact that we have millions of unprofessional developers is what creates a bad reputation for the profession.
To make things worse, people, that do not know much keep reinventing the wheel and make exactly the same mistakes, that where done before them, just because they did not have this schooling and do not know better

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

7 Discuss