Wow, to read the positive reviews of SOA and what it’s doing for the IT industry, one would be likely to believe that there’s serious transformation occurring because of this architectural approach. Well, the truth is, implementing an SOA design such that real loose-coupling is achieved and that a service does not share a common bond with any other service down to its roots in persistence and all the way up to its consumers, using today’s technology mix, is complex, clumsy and fraught with sandtraps.
I was discussing this topic with a friend the other day who is a big advocate of “just focus on the work and stop worrying about the ideology”. I know this person knows how to develop maintainable and sustainable solutions, so when he says “just do it,” I know that implies just do it using common, agreed upon best practices for developing agile software solutions. So, we kept beating about this concept of sustainability and we both finally agreed upon that the key is focusing on understanding the business. This means sustainability comes from analyzing from the top down, not the bottom up as bottom up results in tactical solutions that do not conform to the needs of the business over time.
I know this last statement is controversial. After all, it’s difficult to accept that if you develop using good component-oriented approaches that you can’t retrofit today’s bottom up for tomorrow’s bottom up. But, the fact is that bottom up expresses the “how” not the “why” and the “how” is limited by the subjective reality of the person(s) providing the information. However, truly understanding the business allows the architect to design to an objective goal that can be presented in whatever subjective ways is needed today.
But, let’s revisit my opening premise that implementing SOA designs today is complex, clumsy and fraught with sandtraps. I believe the complexity stems from the fact that SOA works best and is most easily aligned with loose-coupling when services are stateless. This means that the service retains no knowledge of the consumer prior to or post usage and has no assumed context of the consumer.
Moreover, a service should operate in a deterministic manner and the consumer should make no assumptions that the service will operate differently based on same context. Most importantly, if any part of the implementation is implicitly linked to any other service’s or application’s implementation, then it may not maintain the ability to switch contexts as needed based on the consumer.
In many cases, statelessness is in direct opposition to the goals of business applications, which are rich in user context and assumptions of their environment. Reporting, security and governance are excellent examples of features that are hindered by moving to a loosely-coupled services architecture and, if implemented in a way that leans too heavily toward one particular application’s requirements, limits the service’s ability to operate in multiple application contexts.
For example, if a service uses a single database table that has relationships with other tables (e.g. foreign keys), and the service has no use for the data in those related tables, but yet the database is going to enforce data integrity when this one table is operated upon, thus forcing the service to be cognizant of those relationships, then loose coupling is broken simply based on the virtue that a consumer is forced to be aware of information that is outside of the scope of the service.
Additionally, there has been a strong emphasis on reuse with regard to SOA, to the point where reuse has become the single, determining factor for defining a service. However, reuse is a completely orthogonal issue to SOA. Reuse is driven by two factors, levels of specialization and interface. Low levels of specialization will drive reuse, however, high-levels of specialization do not necessarily invalidate a service design—it just makes it less reusable. An interface is merely the entry point for communication. Thus, we can create reusable components that cannot operate without the consumer’s explicit knowledge of other areas of the system, for example, a program ID, and because of these constraints disqualify it from being loosely-coupled, and hence, not a service in the sense of SOA.
I believe if you review many of the systems that today call themselves SOA you will most likely find service-enabled applications comprised of reusable software components and Web Service interfaces. Because many of today’s SOA platforms do not yet provide the necessary means to really enable true loose-coupling without sacrificing things like data integrity across services, implementing SOA designs today often requires concessions that make the resulting service less sustainable.
8 thoughts on “The Reason SOA Isn’t Delivering Sustainable Software”
How should architects measure 'sustainability'?
The problem with SOA is that it is the new big thing in IT. As such, it is trying to be force fit as a solution to every IT problem. Many people are losing sight of just what SOA is and is not. SOA is an implementation methodology that makes use of loosely coupled services in order to provide end-to-end software functionality required. These services should be completely transparent to the end user. SOA is not a methodology for developing the functional requirements for an IT system and service defnition should have no part in determining business processes. Business process modeling (BPM) should be used o define the required business processes to be supported by the IT systems. The architecture process should break down these business processes into the discreet functionality that is required of the IT system. SOA is one way of implementing this required functionality, but under no circumstances should SOA push back up the process and drive the functional requirements. Based on the functional requirements, and other considerations such as latency, security, etc., SOA may or may not be the appropriate solution to the requirements. If SOA is allowed to do this you are seeing the IT becoming the business driver instead of the other way around. This is a recipe for failure and should be avoided at all costs.
Sure. Many of us have been saying that before during and after the SOA bandwagon was rolling full steam.
The original SOA vision was and remains a fantasy world. There will always be clashes between top-down required services and bottom-up provided services. Loose-coupling is not always a good thing. Etc etc.
Architects and designers need training in architecture, and that means training in trade offs, not singular monocular paradigms.
Yes, Graham, many of us have been saying that for some time, including myself, but I continue to seek out ways to present the information anew as well as using different examples as everyday new people are introduced to SOA and some of those who have been working with this approach still do not fully grok some of these details. Only through diligence can we fully express our point-of-view to the ever growing audience of SOA adopters.
Whether SOA is a new thing or not, the challenges facing reuse of services certainly aren't new. I recall pre-SOA training courses pointing to things that hinder service reuse such as:
– dependence of a service on specific infrastructure and other services to which it delegates work.
– dependence of a service on referential integrity between the data structure it purports to encapsulate and data maintained by other services.
– indirect coupling of clients that share a service.
– ownership of the service interface specification.
– change management and version control of services.
– clashes between required services and provided services.
– potential unreliability of 3rd party services.
– the need to govern any kind of module library.
Not to mention the impossibility of guaranteeing service levels if you don’t know what clients are going to call you.
As the guy who wrote the book on EII, you certainly understand the value of data abstraction and virtualization in general, and how data services can provide reuse in particular.
Lately we are seeing more and more adoption of XML industry standards, for example MIMOSA for Oil Refenery data and PIDX for Oil Well Platform data in the Energy industy, MIEM and ICDL in Defense and Intelligence. These standards seem to help with reuse.
It requires different tooling to work top down from an agreed standard than bottom up from the data. But one approach that works well is to split the work. Applications level developers work top down to link standard web data services to apps. Data people work bottom up to provide access and federation services that attached to the top level standards.
It is a good start.
Regards, Bob Eve, EVP Composite Software
Bob – all engineering is a balancing act between pragmatism and design. You can get a lot of work done using the approach you've outlined and meet critical customer demand, however, over the long haul the agility promised from SOA will not be delivered by the outcome of this effort–there will be rework and redesign required to get to the next level. Perhaps after a few iterations of this an organization might reach a level of agility with the final output, but I find that top-down-driven architecture tends to meet the goal of agility much more quickly and requires less rework. Indeed, the only rework required is often due to errors, misconceptions and unaddressed topics introduced during the top-down requirements gathering process.
[…] J., 2009. The Reason SOA Isn’t Delivering Sustainable Software. Tech Evang. URL http://jpmorgenthal.com/2009/06/19/the-reason-soa-isnt-delivering-sustainable-software/ (accessed […]