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.
