Enterprise Architecture (EA) team's role in Solution Delivery

Hello Fellow Architects - I am writing this blog in response to Todd Biske's blog entry on the fact that Enterprise Architecture Must Assist in Delivery.  I am in complete agreement with Todd on this aspect of EA's role in the enterprise.  Participating in delivery of business solutions is a value add that cannot be discounted. Not only does it add to the credibility to EA but it allows EA to be viewed as an ally which makes it easy for it to stay in touch with the "goings-on" in the enterprise.  This partnership and visibility is key to start identifying cross-domain synergies and cross-business process impacts across all the granular projects.

As the leader of EA I have tried to instill this behavior in my team.  My team is now seen as a much more "useful" partner by delivery and not just as a "watch-dog".  Some of this perception change was a result of EA working with delivery in coming up with practical multi-step solutions/ alternatives to EA standards compliance. We reached out to the delivery teams that were under a severe time crunch to come up with Remedial Action plans that incorporated tolerable architecture compromises that would not jeopardize the stability and flexibility of the solution while still delivering business value (on-time!!).  Putting such intermediate architecture solutions in place with hooks for building upon these architecture constructs increased buy-in from both application delivery teams and their business partners.  The result the business partners got to test a more robust solution and were willing to give the project team adequate time in the next phase.  In addition, we were "invited" to review plans for the next phase where we could inspect the program plans that included time to work on the agreed upon architecture compliance roadmap. I have to admit that EA did go down to a much more technical design level for helping with the integration and infrastructure to be able to communicate our architecture roadmap and recommendations. 

EA achieved not just inclusion in the process but also this forced our architects to stay in touch with reality.  This education for our Enterprise Architects allowed us to understand both limitations and constraints of the enterprise and also the technology.  Learnings from this experience were then taken into consideration in refining the technical reference implementation for the EA strategy. Finally, this education has enabled EA to be a more formidable team that was able to bring this knowledge to evaluate vendor "marketecture" thus keeping irrelevant products out of the enterprise.


Your feedback is invaluable.

Thanks.

Surekha,

Business Architecture Dialogue

I will be participating in SOA-Consortium conference being held in Washington DC from March 12-13. One of the main topic I will be focusing on is "Business Architecture". As a result of EA 2010 working group, we have identified Business Architecture as an important aspect of Enterprise Architecture. One of the problems is that there is no clear understanding of what the BA is and how an enterprise should go about creating one.

Surekha Durvasula and myself will be leading a discussion panel to get particpants to talk about their understanding or lack of understanding of BA. Being in Washington, I am sure the dialogue will involve public sector's take on this topic. It will be interesting to see how some of these concepts translate in a public sector settings.

Will let you know how it turned out.

Ashok

Best Practices: Establishing Enterprise Architecture Teams

In one of my previous post I had published the first draft of the presentation on Establishing the Enterprise Architecture team. Based on some feedback and my own experience, I have now updated it with the following additional details:

1. The strategic role of the EA team
2. Enterprise Blueprinting benefits and guidelines
3. Enterprise Architecture Review process

and finally the EA domain model from the SOA Consortium EA 2010 effort. Please click here for the pdf version and do drop me a line at feedback@soablueprint.com for the PowerPoint version.

- Yogish -

Best Practices: Establishing Enterprise Architecture Teams

Recently I have had a number of conversation with some key decision makers of various IT organizations and the common questions I got asked was to explain the process of establishing enterprise architecture teams.


This first requires the understanding the various IT organization patterns (models) as well as the evolution (maturity*) of the EA teams. My initial thoughts on this are available here.

Based on the feedback / comments from the community, I plan to take it to the next level of document the entry and exit criteria as well as the deliverable by the EA teams though each of phases.










* As there are already a lot of maturity models out there have decided to stay away from that term