Looks like the SOA Manifesto went public recently. I wasn’t invited to participate, so what does one do when not invited to a party? It’s quite obvious—you tell everyone how bad the party was, right? Ahh, High School memories revisited… Any case, I commend the community for coming together to vet through definitions, principles, and value statements (Heck, Even the SOA is Dead blogger was there, which I find really ironic.) However, I feel a few key points were missed and below are my critiques of the 6 value statements. Keep in mind that my critiques aren’t intended to poke holes in the value statements just due to my lack of involvement; rather, I truly found the value statement to be confusing, not accurate, and a few that are a lot broader than just SOA. I tried to put myself in the shoes of a SOA newbie who is using this to grasp SOA for the first time, and therefore felt obligated to point out areas that could use improvement. I truly hope this is constructive and maybe we see a 2nd version of the manifesto that incorporates this feedback (how Agile would that be?). Please call me and I’m more than willing to help. I love parties!
Value Statement Critique
#1 Business value over technical strategy. This was easily my favorite value statement. In my own Blog, I called it Business Visibility and Understanding over IT Priorities. Clearly, everyone must agree that our goal is to create business solutions. Conclusion: Great statement! The business does always come first! That’s why we’re here!
#2 Strategic goals over project-specific benefits. I am not sure I can agree with this value statement in the fact that I don’t always believe that strategic goals trump project specific benefits. My feeling is if you take this philosophy, you may never get your SOA project started or out of the gates. My rationale is that in order to get SOA funded and jumpstarted, you need to produce something that is demonstratable and appealing to the business, in a very rapid implementation. How else do you get initial buy-in? My feeling is that (1) this value statement is more academic than practical (2) this value statement is also a lot broader than just SOA…So I am compelled to proclaim, Isn't this what the original Agile manifesto is supposed to avoid-- academic principles that are difficult to follow in practice and too abstract to actually leverage?? I think there could have been a more SOA-specific statement in here, while this is more Enterprise Architecture, touchy-feely. Conclusion: I love the idea of everything being strategic (we don’t like tactical), but not sure this will statement work (especially in this economic climate!). Isn’t this what made SOA Dead? Now, do I think one should ignore strategy? No, there is certainly an overarching strategy and vision to work towards something greater and more holistic along the SOA Roadmap; however, I do think SOA needs to start from the ground-up to gain proper momentum and business-level buy-in and the only way to accomplish this is through incremental project implementations that have a discrete goal, are demonstrable, and appealing to the business.
# 3 Intrinsic interoperability over custom integration. I have mixed emotions on this value statement. I believe interoperability is one of the leading principles of SOA, but I also think it’s a bit confusing to have that value prioritized over "custom integration". I don’t think we are comparing Apples to Apples here. I think a better wording of this statement would have been "interoperability over individual silo's"...in my blog I stated "integrated systems, processes, and people over individual silo's". The problem with the "custom integration" wording in this statement is most legacy systems require custom integration in order to make them interoperable! Not everything is component-driven, plug and play or "configuration driven design", which to me are the opposite of "custom integration". I’ve seen a lot of custom integration in SOA, and it was required for the proper transformation of the system. Conclusion: I like the first part of the statement (Interoperability rules!), but find the second part to be inaccurate and confusing.
#4: Shared services over specific-purpose implementations. I do like the concept of Shared Services, as I find re-usability one of the leading principles in SOA. Again, I'm not in love with the 2nd half of this statement, as I'm not sure it is accurate. I feel very strongly that there are many specific-purpose objects in SOA architecture and required throughout the implementations and design. Not every service is going to be a Shared Service or a Business Service. For example, data services or IT services are usually very specific to the system they are interfacing with or rule they are enforcing. Take any data service that is part of the CRUD model on a legacy database—is that a shared service or a specific purpose implementation? Conclusion: I like the idea and whish everything could be reusable, but don’t want to undervalue services that are not!
#5 Flexibility over optimization. This statement gave me the most heartburn. Simply put, I don't agree with this statement. I believe flexibility and optimization are mutually exclusive and therefore one should not be valued over the other. How can you value one over the other? It’s been very clear to me that some services could be static but value optimization more than flexibility. For example,
A high speed transaction in a Financial Services business process would value optimization much more than flexibility. I feel a more appropriate wording of this statement would have been “Flexibility over rigor”. This I can agree with that agility and adaptability are leading principles. But, so is business process optimization. Let’s not forget software engineers, that there is always a trade-off of performance vs. agility in software programming and at the end of the day, some applications (and services) need more speed and acceleration over flexibility and agility. It is always a case-by-case basis. Conclusion: Misleading prioritization. Would really like to see this re-worded and re-released to clarify.
#6 Evolutionary refinement over pursuit of initial perfection I like this statement, as it enforces the iterative nature of "Agile lifecycle and management" and leads one to believe that an early feedback cycle will be incorporated. However, I have to ask, is this principle really specific to SOA? Isn't this just a re-hash of Agile Principle #12? Conclusion: Love this value statement, as I think iterative, early feedback is the way to go, but I think this statement applies to more than just SOA-- any project being implemented should follow this statement, and therefore I diminish the value of this statement only because I feel we heard this before in the Agile Manifesto.
Not sure that I can follow your argumentation in #2. In cases where "you need to produce something that is demonstratable and appealing to the business" a strategic investment could be made to show the benefits of SOA. This is an approach we successfully use with our customers...
ReplyDeleteJordan,
ReplyDeleteI think your observations are pretty spot on. I think what you are pointing out is more practical versus academic. Discussions on SOA tend to degenerate into academic type matches all the time, #3 was the hot one for me. That one is straight out of la la land. :)
That was one of my biggest issues with the folks who came up with the manifesto, very smart people, but not a lot of folks from the trenches. You really need both to have a balanced as well as practical viewpoint.
markg
Peter-- I agree with your point. My point might hit home better with an example. For customers who are starting with SOA, and want something rapid to demonstrate to the business, we often find we can't go after the most strategic requirements; instead we focus on a "low hanging fruit" project that is still valuable to the business. This way we don't bite off more than we can chew, as the more strategic services can be very time consuming to design and develop. I certainly agree that strategic is what we often strive for, its just not always prioritized over project-based services when developing SOA.
ReplyDeleteThanks for the kind words and vote of approval Mark!
ReplyDeleteIf we describe projects as SOA projects, we have lost the plot! Well almost. A SOA project (and it should be a rare beast) is a project to prove out something in the architecture. We anticipate that it may not have direct business value. Now a project delivering business value, that's a different proposition. It should be couched as the project it really is FROM THE BUSINESS VALUE perspective. Oh, and if it happens to use a technology or architecture framework, so be it.
ReplyDeleteImagine a project with a litany of technologies involved (Linux, Oracle, IntelliJ, Spring, Hibernate, Internet Explorer, Fiorano ESB, Camel, Intalio,...) Yes that's a confusing list of technologies for sure. Apart from the suppliers of all those technologies, who would ever think to describe the project as a Linux project or an Oracle project?
Likewise SOA if all those underlying technologies were used in a project that used a Service oriented Architecture, would calling it a SOA project make any more sense than calling it an Oracle project?
Excellent point Chris! I agree. I try to not use the words "SOA" when doing a project that is either centered on SOA or uses SOA principles...hmmm...this could be a future blog topic. I like when Mr. Paul Ketrick, Institute for Defense Analysis, said he uses his iPhone to sell SOA or SOA-like projects to his business teams...Great idea!
ReplyDeleteHi Jordan,
ReplyDeleteExamples work great for me. Thanks!
There is more common ground than assumed...
I did a short blog post at http://businessanditarchitecture.blogspot.com on this.
ReplyDeleteSo feel free to plagiarize, lift, reference or disagree!
Jordan,
ReplyDeleteYour points are well-made and well articulated. However, in #2, I disagree slightly with both your comment and the SOA Manifesto. Strategic considerations are always needed when introducing new/novel technologies. The question is how are those considerations applied. For service orientation you are quite right in stating that an incremental approach using tactical projects is necessary. Selection of those tactical projects, though, requires a consideration of the overall business strategy to ensure that you've selected appropriate tactical targets and not irrelevant, "toy problem" types of projects. If you do the latter, you run the risk of having those not in complete agreement with the approach (can you say stakeholder) saying that you've not demonstrated any value, just that it's technically feasible. The bottom line for any commercial enterprise is understanding how a particular architectural strategy/approach contributes to the overall value of the corporation, i.e., shareholder value (whether private or otherwise). Since the corporate strategy is usually focused on that value, alignment with that strategy is crucial. If introducing a new architectural strategy doesn't produce or enhance value for the corporation in a demonstrable fashion, it will not be perceived as useful or worth the effort.
Jordan,
ReplyDeleteI'm the poor guy that has to sell SOA... I like your comment in #2 very much but you need senior management sponsorship. Many IT organizations have tried to implement SOA but crashed and burned. Mostly because SOA is not a strategy as such but just a (very good) means to an end. Also many projects are traditionally siloed environments (show stopper for shared services like approach)and bound by factors like risk, time and money. And 'new technology/architecture' is/are the usual suspect(s) for an increase in those factors, unless SOA is appreciated as an important mitigator for those factors. But there is no sane project leader willing to find out! Therefore SOA needs to be adopted enterprise wide and should set the boundaries for every IT project. To achieve that the incremental approach you're suggesting is very useful in bringing strategic goals and SOA closer together. But with lack of Senior Management sponsorship you're toast! I'm implementing this approach with one of my customers currently, with the proper sponsorship, and it works!
Hans-- I completely agree on sponsorship and that is certainly a Leading Practice to SOA adoption-- Great Point! Many times when introducing SOA, I find more non-believers than believers and we are trying to educate and evangelize "why SOA approach is great" but there are always those who roll their eyes at me. Like a religious evangelist, we can't convince everybody. But, if the Sr. Leadership puts down a commandment, the constituents who don't believe have no choice to follow or leave the company :-) (sorry for the Biblical parallels, but its a great analogy!)
ReplyDeleteJordan: Maybe your doubts about the Manifesto come from the fact that a Manifesto is "a public declaration of principles and intentions". It is not a guideline nor a collection of best practices. Many of your valuable comments seem to apply more to the How-To aspects than to the principles. For example, Thomas Erl in SOA: Principles of Service Design, states clearly that all SOA Principles cannot always be fulfilled 100% in all SOA projects, and each SOA project will demand some trade-offs. It seems to me you slightly overstress the trade-off aspects over the principles. Did I read you correctly? But it is still good reading and will be looking forward to more.
ReplyDelete