Gene Leganza, Forrester VP Research wrote a post today titled “Babies, Bath Water, and Enterprise Architecture Maturity Models”. He gave an overview of why he discounted capability maturity models in the past as a technique for maturing EA.  In the post, Gene wrote positively about the roadmap approach we use to plan, mature and assess our EA practice – our EA roadmap.  I will keenly follow any comments and feedback from Gene’s blog post.

Here are the links to my earlier posts on our EA CMM approach that Gene referenced:

Gene, thank you for commenting on our roadmap approach. I will be looking into the “Goal-Question-Metric” technique you mentioned to further refine our approach (and I will blog on it when I am ready!).

If any of you want the templates, just email me at ldesousa12 AT gmail.com and I will be happy to send them to you.

 

In my conversation with Gene Leganza, Forrester VP Research last week ( @gleganza), we spoke about how to address delivering technology in a consistent manner. It inspired me to write this post about our Solutions Council. Here goes:

How do you handle service requests in your IT organization?

Have you adopted an IT Service Management approach?

Can you confidently articulate standard solution architectures for commonly requested services?

In the past, we struggled with a lack of consistency in our technology solution delivery.  Even though we are a centralized IT department, clients received different solutions and services depending on who they contacted.  Imagine how confusing it was for our clients; they could get application solutions from one of LAMP, Oracle, Microsoft, and Lotus Domino application platforms.  Two clients with similar requests could get two different solutions based on which developer they talked to. This further added to the complexity of the application portfolio we manage – meaning more time spent on “keeping the lights on” and less on delivering new solutions.

Fortunately, we laid a foundation to address this ongoing challenge. First, we implemented ITIL Incident Management and the Service Desk function allowing for a single channel for all IT incidents and service requests. Next we built an Application Portfolio and did some analysis discovering how many application delivery solutions we already had in place.  Third, we built a Business Analysis practice to assist our clients in articulating their requests especially those that might require a technology solution.

We made several attempts to get our application developers into the same room to think about and articulate standard solution architectures.  Unfortunately, all this did was further enflame existing technology religious wars.  In one meeting, a developer go so angry that he stomped out of the room and refused to participate in future discussions. Now this could be my lack of facilitation skills but some technologists are more change resistant than others; especially when it comes to their “favourite” technology.

In the fall of 2008, we established our Solutions Council to address our lack of consistency in solution delivery.  The solution council is chaired by a Solutions Architect and hase experts from the following architecture layers:

  • Network
  • Server
  • Storage
  • Application Development – LAMP
  • Application Development – Oracle
  • Application Development – Microsoft
  • Business Analysis
  • Presentation – Web Design and User Experience
  • ITSM – Service Desk
  • IT Security
  • Enterprise Architecture
  • IT Services Management

Solution Architecture background:

  • emerged from Enterprise Architecture as a discipline to guide to support a client’s short term business needs
  • applies EA Guiding Principles to solution recommendations – “Reuse – Acquire – Create”
 

On August 11th, Gartner announced a “new approach for enterprise architecture” that they labelled “Emergent Architecture”.  I got a chance to read some responses from Todd Biske, Mike Rollings, and Dion Hinchcliffe.  Thanks for the great insights and commentary.

In the press release, Bruce Robertson, Gartner Research VP states the two characteristics of “Emergent EA”:

  1. “Architect the lines, not the boxes – which means managing the connections between the different parts of the business rather than the actual parts of the business themselves.”
  2. “It models all relationships as interactions via some set of interfaces, which can be informal and manual”

On characteristic 1. is if you only look at the connections between parts of the business, how can you look for opportunities to reduce complexity, increase efficiency and implement reusability? I believe enterprise architecture is about the whole organization and its environment, not just pieces of it. As an example, our EA practice encompasses IT Service Management (ITIL), Business Analysis (BA) and Program Management (PMO).

On characteristic 2. , again all this says to me is to take a “user experience” approach to describing the architecture. This is nothing new as far as I can tell … perhaps I am missing something?

Now to look at the 7 properties that differentiate “emergent architecture” from “traditional EA”.

  1. Non-deterministic – “… decentralize decision making to enable innovation”.  I don’t see this as anything new. We address this with our technology lifecycle and our technology governance models. We ensure our architecture has a place for innovation in the R&D phase of the technology lifecycle and in the Innovative area of our technology governance.
  2. Autonomous actors – “… devolve control to constituients”.  Being that we grew our EA practice out of IT and that I was a one person team, I never was able to “control all aspects of architecture”.  Working collaboratively, within a technology governance framework allows autonomy based on funding, support and impact our practice influenced the architecture adopted by our community. Again, I do not see how this is different from our existing EA practice. Implementing data stewardship in our business areas is an example of autonomous acting within our EA.
  3. Rule bound actors – “… define a minimal set of rules and enable choice”. What EA practice has not started with some set of guiding principles? Enabling choice is fundamental within an architecture as long as it respects the established guiding principles. I blogged on this here and here.
© 2007-2012 Enterprise Architecture in Higher Education - Leo de Sousa Creative Commons License
Enterprise Architecture in Higher Education by Leo de Sousa is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.
Based on a work at leodesousa.ca.
Suffusion theme by Sayontan Sinha

Switch to our mobile site