Open Group SOA Governance Framework

The Open Group SOA Governance Framework provides context and definitions to enable organizations to understand and deploy SOA Governance. It describes SOA Governance; defines an SOA Governance Reference Model (the SGRM) and its constituent parts; and defines the SOA Governance Vitality Method (SGVM), which assists an organization in customizing the SGRM to realize its customized SOA Governance regimen.

 

Open Group Governance Framework - Governing Processes

This generic reference model for SOA governance is provided as a standard, to be used by companies to create (and constantly monitor and update) their own specific governance model and best practices. The SOA governance framework may be used in the context of another governance framework, such as COBIT or ITIL; the SOA working group did a mapping of COBIT to this framework as part of the framework development process, and plan to do more in the future in order to help organizations preserve their investment in COBIT/ITIL training and implementation.

The SOA Governance Framework will be available here for free download:

http://www.opengroup.org/bookstore/catalog/c093.htm

 

Advertisements

SOA Maturity Models

Over the past week another SOA maturity model emerges. The Open Group SOA Working group released a new maturity matrix (OSIMM) for the identification of where your IT organization is on the SOA continuum.

OSIMM is positioned to be a strategic planning tool that is used to assess where you are along the SOA continuum relative to a standard, vendor-neutral maturity model, and help create a roadmap for how to move on to the higher levels of maturity. At the heart of it is the OSIMM matrix, with maturity levels as columns progressing from left to right, and the different organizational dimensions being measured as rows: business view, governance and organization, methods, applications, architecture, information, and infrastructure and management.

Open Group SOA Maturity Matrix OSIMM

Within each cell of the matrix there are indicators for that dimension and maturity level: for example, if you’re using object oriented modeling methods, that indicates that your methods are at level 2, whereas using service oriented modeling would move you up to level 4 or 5 in the methods dimension. Behind this matrix, OSIMM includes a full set of maturity indicators and attributes, plus assessment questions that organizations can use to determine where they are in terms of maturity: each dimension can be (and likely will be) at a different level of maturity.

While it is stated that the OSIMM is vendor neutral, keep in mind that this was created largely from Service Integrators (SI) and vendors. However, this isn’t necessarily a bad thing as long as there isn’t a conflict of interest to push/lock us into unnecessary services engagements. 

The OSIMM Technical Standard at no cost and all the materials are located:

http://www.opengroup.org/bookstore/catalog/c092.htm

 

Other Maturity Models

OSIMM isn’t the only game in town when it comes to maturity models. Below are some others used in the industry. As you will notice, these are all provided by SI’s or vendors. While there is good concepts and ideas in these they are not compiled in an open industry forum. This is a large disadvantage to customers as it hasn’t be vetted openly.

Infosys SOA Maturity Model

Microsoft SOA Maturity Model (SOAMM)

IBM SOA Maturity Model (SIMM)

Sonic SOA Maturity Model

image

Zapthink SOA Maturity Model

 

The Top 10 Enterprise Architecture Mistakes

This past week I found a very interesting piece of guidance from the  Gartner Enterprise Architecture Summit 2009. I was planning on writing a piece like this myself, but thanks to Scott Bittler, he has made my job a lot easier. 

Scott Bittler, a research vice president at Gartner, says that “The key for enterprise architects is to create not the perfect or most elegant architecture for the moment, but the most adaptable architecture for the future. EA is a challenging discipline and careful attention to the basics can mean the difference between failure and success. Avoiding the pitfalls in the first place is much easier than climbing out of a hole you’ve inadvertently tumbled into. Applying the ways to avoid these pitfalls results in achieving EA benefits faster and reduced risk of programme failure. It will also improve the credibility of IT among business leaders”.

  1. The Wrong Lead Architect: Gartner identified the single biggest EA problem as a chief architect who is an ineffective leader. He or she may understand EA well but has ineffective leadership skills that even a good organisational structure and staffing levels cannot overcome. Gartner recommends that such a lead architect be replaced by someone with strong ‘soft’ skills such as enthusiasm, communication and passion, as well as being well respected and strategically minded.
  2. Insufficient Stakeholder Understanding and Support: This happens when employees outside the EA team don’t participate in the EA programme, EA content is not used in projects and management questions its value. Gartner’s solution is to make EA education and communication a top priority to secure executive-team sponsorship. “The key is to ‘sell’ first and architect later,” said Mr Bittler.
  3. Not Engaging the Business People: When IT and business goals are not aligned, resultant problems include non-technical people trying to make technical decisions while enterprise architects become too reactionary and tactical in response to projects. To overcome this, Gartner recommends that enterprise architects get involved in the development of the business context and engage jointly with other employees in the business architecture.
  4. Doing Only Technical Domain-Level Architecture: This dated EA approach is still in use in some organisations and is even narrower in scope than technical architecture. Holistic EA best-practice is much broader as it includes business, information and solutions architecture.
  5. Doing Current-State EA First: Successful EA provides prescriptive guidance but current-state EA does not, so it delays delivery of EA value and hinders the creation of good future-state EA. “The temptation is often to do the easy – current-state – EA first,” said Mr Bittler. “Instead, establish the business context and then focus first on future-state EA.”
  6. The EA Group Does Most of the Architecting: This is a pitfall because the EA content is typically off the mark as it was not informed by those on the business side. There is also consequently no buy-in for the EA. The primary job of architects is to lead the EA process rather than impose EA content on the organisation. They should form virtual teams to create content and seek consensus on the content.
  7. Not Measuring and Not Communicating the Impact: The value of EA is often indirect, so it may not be obvious to everyone in the organisation. This then exposes the EA programme to risk of failure. Gartner recommends that enterprise architects create a slide to demonstrate each success story of EA applied to a project. They should include measurement and documentation of EA in the programme plan.
  8. Architecting the ‘Boxes’ Only: Enabling better business agility and integration is key but architecting standards for the ‘boxes’ (business units) in process, information, technical and solutions models doesn’t address this. Integration and interoperability standards are high EA priorities and must account for more than just technical architecture. Architects should focus more on the links between the boxes.
  9. Not Establishing Effective EA Governance Early: Enterprise architects must resist the temptation to wait for more architecture content before setting governance processes and instead develop content and governance in parallel.
  10. Not Spending Enough Time on Communications: Key messages about EA are not intuitively obvious, so enterprise architects must work to educate the business. It is critical that organisations develop and execute an EA communications plan with messages tailored to each audience.

These are all really great points. Since Scott did a great job of articulating these I only have a few comments:

On item #1 with regards to leadership, I believe that this is critical as well. I have personally have observed very smart and talented Chief Architects not be as successful as they really could be with their programs. Often times as a result the EA team disbands or reorganizes. While I do agree that the soft skills defined are important (enthusiasm, communication and passion, as well as being well respected and strategically minded), I think there are other aspects are critical as well. 

  • Must be able to Sell EA. Not the used car salesman version but truly be able to articulate the value in terms that everyone at the decision making table understands. 
  • Chief Architects must be pragmatic. It is easy to over-archtiect / engineer things like governance, process, standards or solution architectures. Understanding what is realistic and achievable at a given time (based on many factors of the organization) will ensure greater success and adoption by the organization.
  • "Think Strategically but Act Tacitly", remember that as you make your decisions. The audience, organization or even your technical capabilities within the organization may not be ready for your more advanced thinking. Like in chess, make sure you have a direction but check mate is always several moves ahead.

I look at item #2 , #7 and #10 as part of the same overall strategy. Chief Architects must be able to foster communities in the enterprise. These communities will be the drivers behind the destiny of the organization, not EA. Enterprise Architecture is the facilitators, providers of non-bias opinions (ideally), check points for other enterprise considerations, etc. This is a key input into the governance processes that will be enforced. The result will be an organization that is behind governance because they helped create it. 

Another piece that will ensure success for Chief Architects is building a communication plan. While communication was explicitly called out with the great advice on tailoring your message, I would include a few more considerations that will add a positive impact on your communications:

  • Frequency, communicate often! You can never over communicate the successes and tangible impacts to the organization. 
  • Transparency, not only should you communicate often but also communicate as much as you can, even if the artifacts you are creating are in draft. Items to communicate: architecture decisions, architecture review board artifacts, solution architectures, technology life cycle roadmaps and decisions and governance materials.
  • Feedback loop, make sure there is a feedback loop and ensure that it is heard. I have observed this time after time where architects or developers say they don;t have a voice or do not understand why a particular policy exists. Provide a feedback loop so they can ask questions, challenge and debate openly with EA. 

On item #4 with Enterprise Architecture only preforming IT Architecture… I agree with this in theory, but with this one, it really depends. It depends on so many factors that I would rather talk about it in another post rather than here. But very simply through my discussions with other enterprise architecture organizations is that most companies are just not ready or understand the need to do this. The overwhelming number of organizations I have spoke with over the past two years have EA reporting to either the CIO or CTO (and there are even some below those). In this model there a so many organizational challenges to overcome. If companies where truly ready for this, these companies would have the office of enterprise architecture report to the CEO directly. Other factors here are maturity and general understanding of what value EA provides. 

I would agree with this if the organization has a mature EA capability but if the company is new to EA, no dice. 

Item #5 talks about not doing current state first. I agree whole completely here. But at some point you will have to do analytics on what you have. Instead of "boiling the ocean" on all of your IT systems, pick only a few of your mission critical ones and start there. The goal here is to focus on the most important systems as they will yield the most return on investment.

Item #8 is talks about boxes and lines that us architects create. I agree we have spent a great deal of time on the boxes and haven't shown the same attention to the lines. I heard this loud and clear at the Gartner EA Summit last year from Brian Burke. I personally don't discriminate against lines but I see how it can happen… 

Item #9 is a bit lite for such a broad and important topic such as Governance. What I will say here is that I agree with Scott on this but a few more qualifiers need to be in there for me. First, Just In Time Governance (JITG). I agree we shouldn't let analysis hinder us from setting up necessary governance areas that are industry standard that EA knows will add value but we need to be careful at what level we implement. This is a delicate balance and again depends on where you are at in the maturity curve. I would love to see Gartner or Forrester put together a matrix that puts this into more context based on organizational dynamics and maturity. 

Like I said before, Scott did a great job here with compiling his thoughts on the Top Ten EA Mistakes. Scott, if your reading… please comment and let me know how far off I am from your intent or thoughts. I wouldn't mind hear back from you on this.

IASA Regional Conference in New York

The IASA IT Architecture Regional Conference (ITARC) will be coming up soon (October 12th 2009) in New York city. IASA has positioned this as a regional conference but it is starting to look like much more. With architect heavy hitters like Grady Booch, John Zackman, Eric Evans, Bill Inmon, Len Bass and others. It is said that this is the first time that all these industry though-leaders have ever assembled in one place.

In addition to hearing keynotes about the state of architecture today from industry  thought-leaders, there will be five parallel breakout tracks and have the option to attend a one day training pre-conference as well.

Either due to the economic pressures or purely to get attendance from more than the NYC metro areas IASA will be a offering a 10% discount off the listed registration fee to anyone who registers using the special user group registration code: chapter2346. Also, for every company that registers three attendees they will get a fourth attendee from that company in free.

For more information see: http://www.iasahome.org/web/itarc/2009/NYC.