Comparing Current Financial Crisis to SOA - Continued

I agree completely with Yogish's views as posted on "Comparing Current Financial Crisis to SOA" and his advice on treading light and having solid justification prior to undertaking SOA style projects.


A) An upfront investment has to be made in performing the right level of business process analysis and business architecture to pick the right SOA service candidates.


B) One should not attempt embarking on SOA with a highly visible project, as these types of projects operate under unwarranted pressure for delivery and with little patience for "architectural constructs" SOA or otherwise!!


C) Any project that is a high return type process with established KPIs and benchmarks is a good candidate for first time SOA implementations. Here gains are measurable (in the form of cost avoidance, cost reduction etc.) and can be directly tied to SOA-enabling these operational processes.

D) One has to invest in marketing the success of these projects and the services that were responsible for these quantifiable returns delivered by following SOA principles. Advertising the benefits of SOA style services with the benefits rendered by these projects help the business to relate to the abstract constructs such as SOA and so offer a better chance for service adoption. Also, advertising these business services that deliver efficiencies can be shown to offer speed to market gains that can be used for upcoming projects by encouraging reuse.

E) As always one should not assume technology will be the magic bullet. An assessment has to be made to understand if all components of the process/ business capability have to be refactored into services. One has to be open to leveraging legacy assets to reduce risk even if all that can be achieved is establishing a document based interaction or a mediated invocation of the legacy system.

Your feedback is invaluable.
Thank you!!
Surekha -

Explaining the terms "Services-Oriented Architecture"

Recently there has been some interesting discussions on multiple on-line groups on defining Services-Oriented Architecture. My observations has been that a majority of the participants on the on-line forums refer to SOA as an Architecture Style. I would agree with this, however I would not mention this to the non-IT staff. What would they care or know about (Enterprise) Architecture Styles? and does it make any sense for us to explain this to them? We might be better off learning more about their needs instead.

Wikipedia definition starts with "SOA is a software architecture...." and because of this, I would not agree with it. Maybe one of these days I shall get enough courage to change it on Wikipedia :) .

I just read Surekha's blog on Key Best Practices: What is Serivces-Orientation? and am in complete agreement with her that

There is no place for the use of architecture terms, technological jargon or even as much as a mention of the web services or the WS-* stack in this definition!!

I would still define SOA as described in the SOA Practitioners Guide Part 1: Why Services-Oriented Architecture? . The SOA Practitioners defined it as follows:

SOA is a business operations strategy for leveraging information to meet the organization’s objectives, such as increasing overall revenue, boosting customer satisfaction, improving product quality, and enhancing operational agility.

Following are the reasons why this still makes sense to me:

First: Business is responsible for their own strategy (some interesting anecdotes) and yes! IT should (note: not MUST - IMO) have a seat at the table to help influence the strategy. Once the business stategy is established it is the responsibility of Business Operations to execute on the strategy. This is where IT comes in - parnering closely with Business Operations in developing the Business Architecture. People from the IT Organizations generally interact with Business Operations on a day-to-day basis. The IT Leadership does interact with the business executives but more on a periodic basis. It is for this reason I prefer the term SOA is a Business Operations strategy for leveraging information.

Next: I like all strategies to be actionable, i.e. a roadmap for achieving specific desired goals. For example, the primary goal for SalesForce.com (Disclaimer: I know as much about SalesFoce as most of the readers of this blog) is to most probably to become the primary platform for ALL SaaS solutions in the market. In this case, the business operations folks (sales, services, marketing, finance and IT) have most probably defined approaches for meeting this objective (which could be in form of marketing campaigns, events, sales incentives, partner programs, etc.). In order to execute this strategy they will require services from their own internal IT (yes! they do have an IT Organization) to provide them the capability to execute and monitor the progress (...leveraging information to meet their objectives).

Finally: I agree Todd's and Rob's thoughts about the term "The Business" - my observation is that this is not limited to IT Organizations. This is true for all organizations where I have heard sales executives refer to the "Those Marketing Operations folks" and so on. The only company where I had seen systematic approach by executives to rediret the entire company to consider themselves as a single team was at The Coca-Cola Company (or at least that was my observation in the early 90's - when I was in their IT organization). So even though I agree with their frustration with the term "the business" - I still prefer the term Business Operations in the definition.

Hope this was interesting and do drop me line to discuss this further, if interested.

- Yogish Pai