Friday, June 29, 2007

Beyond SOA -- Practice Oriented Architecture (POA)

I just came up with a new acronym -- POA (Practice Oriented Architecture). What is it? Well looking at SOA (which revolves around services and service orientation) it beggs the next question what is beyond SOA? I'v been thinking about it for some time.

SOA promises composite applications that closely model the way organization do business -- that is SOA promises reusable buinsess services. That is great.

In my view POA (or some variant of the acronym) will take hold soon after. What are the key elements of POA. Composition of business services into "Practices" -- goal oriented composite business processes. POA relies on a combination of proven business services that together form -- Practices. Practice is a polished set of business services that have been perfected or almost "evolved" as a result of various business activities. It also focuses on goal orientation rather then compositions. Meaning that the architecture will promote evolution of practices from so so to good to better to best. Obvious questions would be "how do you measure good, better, best"? I dont have an answer, but working on it :) -- maybe by revenue, customer loyalty, or some other key business metric.


You might say, "How is it different from BPM?" Well, in my view BPM still falls into SOA space and does not address the questions of how composite business services form into "Practices", how do you consistently improve and integrate composite business practices. Practice to me is a discipline that lets companies excel at what they do. SOA will let them integrate, POA will let them take to the next level.


The new discipline will have to focus on how to create, improve and deploy best of breed goal oriented processes that can almost self evolve.


Or may be, I just like new acronyms. :)

Wednesday, June 20, 2007

SOA Governance equals Web Service Management?

Today I read an article from ZapThink -- "Divorcing SOA from Web Services", where the author is basically saying that many people in the industry incorrectly equate SOA with Web Services. I came across similar situations. Every time there is a talk about SOA management it is automatically being associated with Web Service management. I guess most organizations are implementing SOA using Web Services. Come to think about it, if an organization is trying implement SOA, what technologies would they use? Is Web Services the only viable way of creating service orientation? Well surely CORBA is a candidate, but is anyone actually doing this? Big part of SOA is not just service orientation but also service interoperability.

Did Web Services become a defacto standard for developing service oriented composite applications? Clearly Web Services is not enough to achieve true SOA implementation, that is where ESBs (Enterprise Service Bus) come to the picture.

The article also introduces the term SOI (Service Oriented Infrastructure) which is basically the building blocks of the SOA paradigm such as message bus, ESB etc. So organizations must effectively translate SOA into specific SOI as well as come up with best practices to support it. So the question is when do you truly achieve service orientation? I guess that would be organization specific. If SOA is about business services -- SOA implementation would mean to compose/create reusable business services that can be integrated and reused on-demand. The granularity of the service interfaces and would be organization and business centric.

So if Web Services follow "bind-publish-use" paradigm, SOA would be "bind-publish-compose-use" where each composition of services is in itself a business service can be used as independent service.
That makes sense.

Wednesday, June 6, 2007

ITIL and SOA -- merging best practices

There is a lot of traction around in ITIL (Information Technology Infrastructure Library) and SOA (Service Oriented Architecture). While SOA provides best practices around technology integration ITIL is focused on best practices around IT Service Management (ITSM). Effective implementation of the both strategies supposed to yield capable IT infrastructure on one end and tight IT governance on the other. Well, that is true if concepts and practices can be translated to implementation easily -- not quite the case yet.

ITIL, while providing a solid base, in practice is difficult to achieve on the end-to-end basis. So organizations pick tools that fit into the ITIL model -- yet may not readily integrate with one another. The result is organizations that on paper are ITIL compliant yet in reality can not fully realize ITIL vision.

So how should deal with strategic long term direction and yet deal with short term practical issues of SOA governance (using ITSM)?
  • Organization need to adapt ITIL practices to fit the size and requirements (current and future)
  • Technology aquisition and adoption must always be evaluated against: todays needs and always must be inline with long term strategic goals.

While it sounds quite obvious, it is not easy to enforce especially in large organizations. What is happening is that long term strategy is often times traded for the short benefit often on project by project basis. This in term creates a complex technology and tool mix that is 1) complex and 2) costly to maintain going forward.

Some organizations setup archiecture committees or review boards, which review and approve all tehnology aquisitions and adoption within the organization. Their tasked one to ensure that best practices are enforced on end, and also review and ammend the same practices on the other.

The role of such review boards is essential especially when organizations are trying to implement such broad practices such as ITIL and/or SOA.