Is SOA Dead! Nope.

Year 2009 started with bang, SOA is Dead; Long Live Services by Anne Thomas Manes. In her blog and subsequent interview in IT Business Edge she emphasized that SOA is dead in business parlance due to it is failed to deliver its promises of aligning IT with business in real time. She advises not to use SOA word while asking for funding in today’s recessionary economy.

But I have simple question, do we as analysts, architects (not as business person) have analyzed why this phenomena is happening. I don’t think so.

When I read her blog entry in starting of year, I thought of protesting. But, then I though of analyzing the whole story wearing multiple hats – IT Service Company, Tool/Platform Provider, Business Person, Analyst and finally as Architect. Nearly a quarter long conscious analysis, has given me few insights:

1. Most of the SOA initiatives started as integration project where services were used as integration medium in stead of MOM. To maximize reach (in terms of market capture and revenue) Tool/Platform Providers and IT Service Companies have added fuel to fire.
2. Most of the established Tool/Platform Providers saw SOA as new business opportunity, so re-branded their Integration Tools/Platforms as SOA one.
3. To maximize their revenue Tool/Platform Provider created grandiose Tools/Platforms which have resulted bleeding IT departments.
4. As usual, Analysts are folks who can offer criticism on every thing. So they provided argument on both sides. They provided criticism on Tools/Platforms, Methodologies and frameworks but sadly, never on SOA independent of vendors.
5. Architects are greatly influenced by Tools/Platforms to which they were conversant. That’s why we see Java Architect, WebLogic Architect, WebSphere Architect, .Net Architect etc in Architects’ resume and at monster.
6. Business persons wanted quick return on their investment (essentially, they want their investment should be like expense) due to business compulsion which prevented them justifying long term investment.
7. Nobody paid any attention to business process restructuring and operation restructuring which are essential foundations of successful SOA.

So, SOA is dead or just acronym SOA has become dirty. Certainly SOA is not dead but we have to work for its acceptance with business people. Business persons sanction budget not IT ones. Whether, acronym SOA remain in vogue or not, it does not matter. So, the core question is how to keep alive SOA and not only alive but healthy and thriving.

1. Understand SOA philosophy (SOA stands for Service Oriented Architecture) independent of Tool/Platform Providers offerings.
2. Technical folks have to understand business realities. Due to present economic conditions business wants quick returns. So, it is time of tiny SOA (not even small), which should fit into grandiose Enterprise Architecture. This world in not perfect.
3. Businesspersons also have to understand that there is no silver bullet; Architecture requires time, money and humans.
4. If acronym SOA has become dirty, change it or clean it. I leave this choice to analysts; it is their job to invent new acronyms.


Underlying fact is, SOA is not dead and will not be dead but morphing itself as Web 2.0/3.0, SaaS, PaaS, BPM, EPM, Cloud computing, etc (Refer: http://architecture-soa-bpm-eai.blogspot.com/2009/03/service-orientation.html).

Further reading:
1. http://apsblog.burtongroup.com/2009/01/soa-is-dead-long-live-services.html
2. http://blog.dhananjaynene.com/2009/01/soa-aint-dead-but-it-certainly-is-transforming/
3. http://blogs.progress.com/soa_infrastructure/2009/01/goodbye-soa-we-hardly-knew-you.html
4. http://technoracle.blogspot.com/2009/01/soa-is-not-dead-but-complexity-is.html
5. http://www.andrejkoelewijn.com/wp/2009/01/06/soa-is-not-dead-were-still-in-the-early-adaptor-fase/
6. http://blog.dhananjaynene.com/2009/01/stop-making-soa-complex/
7. http://rasmussenreport.wordpress.com/2009/02/16/the-death-of-soa-maybe-later/
8. http://soa-today.blogspot.com/2009/02/big-soa-is-dead-little-soa-is-thriving.html
9. http://samisa-abeysinghe.blogspot.com/2009/02/soa-is-dead.html
10. http://broadcast.oreilly.com/2009/01/soa-is-dead-its-about-time.html
11. http://tardate.blogspot.com/2009/02/soa-is-dead-was-it-ever-alive.html
12. http://www.theenterprisearchitect.eu/archive/2009/01/26/soa-is-dead-long-live-model-driven-soa
13. http://www.glaucoreis.com.br/is_soa_dead_i.html
14. http://www.arisblog.com/2009/01/07/technical-soa-is-dead/
15. http://drjbutler.wordpress.com/2009/01/06/soa-in-good-eternal-company/
16. http://havemacwillblog.com/2009/01/13/the-people-who-think-soa-is-dead-are-dead/
17. http://blogs.progress.com/soa_infrastructure/2009/01/soa-wanted-dead-or-alive.html
18. http://www.itbusinessedge.com/cm/blogs/byron/even-if-soa-is-dead-sca-and-sdo-alive-and-well/?cs=30222
19. http://www.itbusinessedge.com/cm/community/features/interviews/blog/why-soa-should-be-dead-to-the-business-but-alive-and-well-in-it/?cs=30407
20. http://www.ecommercetimes.com/rsstory/66104.html?wlc=1237532051
21. http://www.thinkovation.com/blog/index.php/2009/01/14/soa-dude-its-alive-and-kicking/
22. http://jshurwitz.wordpress.com/2009/02/09/yes-virginia-there-is-a-soa/
23. http://www.eweek.com/c/a/Web-Services-Web-20-and-SOA/SOA-Wanted-Dead-or-Alive/

Services Orchestration Design Principles & Best Practices

In real life SOA implementation services collaborate and executes in a particular fashion to perform a process. Process implementation uses Orchestration and Choreography of services. In this blog entry, I would like to focus on services orchestration.

From my experience on Oracle Fusion, TIBCO, Aqualogic and WebMethods I have collected some Services Orchestration Design Principle & Best Practices. I am listing those, independent of Tools/Platforms:

1. Keep Orchestration depth to manageable limit. (Refer: http://architecture-soa-bpm-eai.blogspot.com/2009/01/composite-services-complexity-measure.html)
2. Keep service dependency in manageable limit (Refer: http://architecture-soa-bpm-eai.blogspot.com/2009/01/inter-service-dependency-model.html)
3. Keep granularity of services under predefined criteria. Visit this criterion regularly.
4. Avoid recursive service calls.
5. Classify services as technical and business
6. Avoid complex and huge service contracts
7. Handle anticipated Faults and Exceptions
8. Keep Fault handling and Exception logic out of main process flow
9. Develop compensatory processes
10. Pay attention to Quality of Service (QoS) of services involved in Orchestration
11. Pay governance policies to services involved in Orchestration
12. Remember Separation of concerns
13. Validate messages flowing in a process – in process, and in out of the process
14. Pay heed to vendor specific best practices and design principles
15. Last but not least: Test, test, test, …

Service Orientation

In one of recent discussions, I developed a diagram to understand SOA key concepts.



I am interested in knowing your views.

SOA Evolution

We talk a lot about SOA but we seldom pay attention on its evolution - past, present and future. I have tried to map SOA evolution in terms of increasing complexity.

Service Misconceptions

As the SOA is maturing so the web service, one of the most common way to implement SOA. But misconceptions about Web service are still prevalent among developers, architects and business persons. Here I have listed some of them and giving arguments for them. This list is comprehensive but far from complete.

1. Web services are not distributed objects
2. Web services are RPC of internet
3. Web services need http/s
a. Have you think of JMS, SMTP, UDP etc based services
4. Web services are not for large amount of data transfer
Please refer:
MTOM specification
5. Debugging of web services is impossible
Please refer:
a. Progress Actional Diagnostics
b. XMLSpy® 2009
6. Web service do not support transaction
Please refer:
a. http://www.ibm.com/developerworks/library/specification/ws-tx/
b. http://www.ibm.com/developerworks/webservices/library/ws-comproto/
c. http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ws-tx
7. Web service security is sketchy
Please refer:
a. http://en.wikipedia.org/wiki/WS-Security
b. http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss

ESB Evaluation

I have developed an ESB Evaluation workbook. Use it for your benefit. Let me know about any suggestions, I will be pleased to update the doc.

ESB Evaluation

Publish at Scribd or explore others: Research soa appliance oracle fusion

ESB Evolution

From humble beginning when ESB was nice to have tool in SOA ecosystem, it has grown into one of the central components. Today every vendor who is offering a SOA toolset has some thing to offer which resembles ESB. Broadly ESB is classified as:

1. Message Centric
2. Document Centric

With current wisdom, an ESB should boast of the following capabilities:

1. Message transformation
a. Format Change
b. Enrichment
c. Truncation
d. Combining multiple messages
e. Tearing a message into multiple messages
2. Channel Transformation
a. Single Channel
b. Multi Channel
3. Service Composition
a. Aggregation
b. Orchestration
c. Chorography
4. Routing
a. Content based
b. Time based
5. Contract Transformation
6. Transaction
a. Atomic Transaction - Short running
b. Compensation - Long Running
c. WS Transaction
7. Security
a. Authentication
b. Authorization
c. Non-repudiation
d. Confidentiality
e. Security standards (for example, Kerberos and WS-Security)
8. Plugability
a. As plugin
b. As host of plugins
9. Quality of services
a. Various assured delivery paradigms (e.g. WS-ReliableMessaging or support for EAI middleware)
10. Policy driven
11. Management and autonomic
a. Service provisioning and registration
b. Logging, metering, and monitoring
c. Discovery
d. Integration to systems management and administration tooling
e. Self-monitoring and self-management
12. Messaging paradigm
a. Request reply
b. Pub sub
13. Administrative capability
14. Distributed deployment
15. Centralized management

As SOA tool sets are maturing, ESB capabilities are becoming a commodity. This maturity is happening at the software and hardware front.

I see a future where there will be a couple of open source authoritative ESBs and they will form the core of numerous “me tools” ESBs from open source communities and proprietary vendors. This trend is already evident from the apache web server and tomcat servlet container.

On the hardware front numerous SOA appliances are making splash. As the SOA appliances are becoming more capable, the ESB functionalities are moving into hardware based solutions and SOA appliances will be part of a network infrastructure. I see following features moving into SOA appliances over time:

1. Message transformation
2. Channel Transformation
3. Service Composition
4. Routing
5. Contract Transformation
6. Plugability
7. Quality of services
8. Policy driven
9. Management and autonomic
10. Messaging paradigm
11. Administrative capability
12. Distributed deployment
13. Centralized management

EmTech India 2009: Second Jotting

Now in continuation of my earlier post, the second awakening is hardware and software merger. The example cited at EmTech was emergence of Java as software though it was though as hardware solution. The example seems to me very convincing. After little thinking the second example I came across, Server virtualization. In this case essentially user is faked for single or multiple machines, which hides the otherwise fact.

With respect to SOA, I also encounter one compelling case: XML Appliance. I understand XML appliances are not pure hardware solutions but combination of hardware and software.

Initially I was skeptical but with some investigation I realized that XML appliances do great job in their niche. They take away mundane job of XML processing and make it many times faster and efficient provided applications have right kind of workload. So do XML Alliances are substitute for:

1. Pure software XML processors?
2. ESB (full or part)?

There is no perfect answer for these questions. Answers depend lot on:

1. Capabilities of XML Appliances
2. Peculiar circumstances surrounding the solution.

Here is the brief list of XML appliances in the market:

1. http://www.castiron.com/
2. Cisco AON
3. http://www.dajeil.com/Default.asp
4. http://www.vordel.com/
5. WebSphere DataPower SOA Appliances
6. http://www.vordel.com/
7. Intel SOA Expressway
8. Radware
9. http://www.stampede.com/
10. http://www.prismtech.com/
11. http://www.sonoasystems.com/
12. http://www.layer7tech.com/home.html
13. TIBCO Messaging Appliance


Few blogs and websites discussing XML appliances in SOA ecosystems

1. http://www.nowmagazineblog.blogspot.com/
2. http://soanetworkarchitect.com/
3. http://www.comnews.com/stories/articles/0407/0407xml_appliances.htm
4. http://myarch.com/category/soa
5. http://mkosaraju.wordpress.com/2007/05/24/xml-appliances-and-soa/

EmTech India 2009: First Jotting

Recently I was as EmTech India (March 2 & 3, 2009). The two points has stroked my chord as software professional were:

1. The next technology is mobile phones
2. The differentiation between hardware and software is blurred

I will cover these two topics in two different postings.

First thing first, affect of emergence of mobile technology in enterprise architecture, SOA and BPM. Since mobile technologies are maturing fast and consumers are adopting them fast, they are bound to affect how applications are architect and designed with respect to user interaction. Now more and more persons will access applications over cell phone which gives one more type of UI to cater for. But still it is to be studied that is there going to be any fundamental change in architecture to incorporate mobile technology in enterprise architecture.

On the cursory look following questions needs to be answered with emergence of mobile technology and its deepening penetration:

1. Do mobile users affect Enterprise Reference Architecture?
2. Does only user interface affected?
3. How to access long running processes over mobile devices?
4. How does limited connectivity affect applications architecture?
5. How does limited processing power affect applications architecture?
6. How does absence of standards on the mobile phone affect applications architecture?

Separation of Service Implementation and Service Interfaces – Service Design Pattern

While analyzing the numerous several services implemented across business domain using various technologies, I observed few that there is clear distinction between neatly designed and messy services. In clean services there has been effort to separate implementation and its interfaces while in not so clean, implementation and interfaces are coupled.

While designing the service most of the time developers have forgotten the concepts of decoupling.

This pattern can be explained in form of picture as: