Hot off the Press - TOGAF 9 Applied: One Iteration at a Time

TOGAF Version 9 came out with a bang on February 2, 2009. Although the core of TOGAF -- the Architecture Development Method (ADM) -- remains the same, there are many changes within the framework making TOGAF even more modular and providing further standardization, guidance, and support around how the framework is applied in practice. Key enhancements include the addition of the newly defined Architecture Content Framework making TOGAF into a truly standalone framework and a detailed set of guidelines and techniques for applying the ADM in a number of real-world scenarios. Another major change is that TOGAF 9 has eliminated the Resource Base transitioning much of it to the newly introduced Architecture Capability Framework. Portions of the Resource Base have also been moved to the relevant TOGAF sections. For example, the complete discussion on Business Scenarios, which was formally part of the Resource Base, is now its own chapter in Section III: ADM Guidelines and Techniques of the TOGAF 9 specification. In this article, I will focus on one particular enhancement to the TOGAF 9 framework -- the formalization of iterative application of the ADM (and hence TOGAF).

Check it out at http://www.ebizq.net/topics/soa/features/11247.html

What's the Best Way to Measure SOA Success?

The Free Dictionary defines success as "the achievement of something desired, planned, or attempted." Success in an SOA initiative follows the same definition. SOA, in its purest form, is meant to align business and IT towards a utopian agilily. Real-world SOA projects typcially have more short term goals in mind such as reusability, maintainibily, interoperability, etc. Regardless, the success criteria of any SOA initiative should be defined upfront based on the goals of that initiative. It goes without saying that proper care should be taken that all goals and success critera are SMART and agreed to beforehand by all stakeholder in unambiguous terms. Ultimately, just like beauty, I think success, too, is in the eyes of the beholder.

Hot off the Press - Enterprise SOA: Five steps to the next frontier

What do enterprise architecture, virtualization, security, business intelligence, and organizational culture have in common with each other and with SOA? If you answered "very little to nothing at all," then think again because each one of these can make or break your SOA implementation.

To find out more check out my latest article on creating an enterprise class SOA implementation, which just got published today in IT World.

http://www.itworld.com/soa/66397/enterprise-soa-five-steps-next-frontier.

Cloud Computing - Who should define the standards?

Personally, I don't think there is a definitive answer to this question; at least not at this point in time. Whether defined by an individual company or by a group, there are plenty of examples of standards that have failed in both cases. For example, CORBA (POA, IIOP, etc.) defined with the full backing of the OMG never really reached its full potential. On the other hand, Java (and its family) created initially by one company, Sun Microsystems, have become de-facto standards that are now supported by a whole community. Cloud computing is still in its infancy. Yes, it shows great promise, but so did Robotics and AI. Cloud computing still needs to prove itself to be viable beyond a few initial applications. As it proves itself, standards will emerge; some defined by an enterprising company and some by a group. The good news is that we have both going on right now. Companies such as Amazon and Google are leading the way with a solid beginning. At the same time, there are community efforts as well with the Open Cloud Manifesto and Cloud Computing Interoperability Forum. What is certain is that plenty of standards will emerge but only a few will survive. Only time will tell which standards will succeed.

Is "Guerrilla SOA" a Realistic Option When the CEO Doesn't Approve Your Budget?

A great question… and one that occurs more often than one might think and most definitely more than it should. In August 2006, I had written an article on SOA Antipatterns in ebizQ. Antipatterns #3 and 4 specifically talk about this exact issue. The antipatterns are duplicated below for convenience:

Antipattern #3: Service Fiefdoms
This is the corollary of antipattern #2 (The "Big Bang" Approach). Here, instead of taking an enterprise view to the SOA transformation, each vertical silo within the company goes off on their own and recreates their applications as services within an SOA. In this case, there is the potential for a lot of duplication of effort due to the lack of an enterprise view. Furthermore, this fragmented approach to the SOA transformation often fails to create reusable organizational assets, which is one of the key benefits of undergoing the transformation that leads to higher organizational efficiency and improved cost effectiveness.

Antipattern #4: Technophilia
This is an antipattern that occurs when the SOA initiative is led bottom-up instead of top-down i.e. when the "techies" are leading the initiative. Instead of the SOA initiative starting with the study of the processes that drive the business, the technology that will power the SOA becomes the apex of the effort. Instead of representing the business, the drivers of the SOA initiative get too wrapped up in technology specifics such XML, Web Services, determining which versions of the various technology standards to use, deciding how much BPEL will be needed, etc. Ultimately, such an SOA initiative does not yield the intended business benefits of creating reusable organizational assets.

The bottom line is that several years of experience has shown that for an SOA initiative to truly achieve its objectives it has to be a top-down effort; both organizationally and architecturally.