Key Lessons – The new and improved Enterprise Architecture Group

When invited to start the Enterprise Architecture Group a couple years ago my only thoughts were how to technologically implement SOA and EDA as the core architectural principles. However, soon enough came the realization that without having access to those who had sound business knowledge and those that knew the core business domains, value streams and the strategic business capabilities it would not be possible to effectively deliver SOA or EDA.


Service orientation of business behavior encapsulated in business applications and the definition of business events that initiate key business processes both require enterprise-wide understanding of business behaviors and business activities. Furthermore, the ability for identifying business services and/or business events comes from being able to abstract business needs that cross business domain boundaries. These skills can be found in a group of individuals being called business architects – a unique group of individuals who can translate the strategic business needs into an action plans that show how to enhance current business processes that support core value streams.


This led me to find resources that could analyze business processes (a.k.a. Process Architecture discipline) and resources that could analyze business information-flow, the value-addition pathways (where by business information is enhanced as it is exchanged across multiple business domains) (a.k.a. Information Architecture discipline). Both sets of these resources have allowed me to embark on true SOA style service definition. So the “new and improved” Enterprise Architecture Group has Process Architecture, Information Architecture (or what the industry calls Business Architecture) and Technical Architecture representatives.


Finally a note about the Technical Architects; my opinion is that, standards are vital but then if the Enterprise Architecture Group is unable to demonstrate the right use of standards in a true production environment this group will be left with very little credibility or be deemed the “ivory tower” group.


Having a cross-functional group of resources has made the Enterprise Architecture Group to be a well rounded group. The Business Architects of the group are in dialogue with the business as they can speak to the business in its lingo while the Technical Architects of the group are able to work with the developers as they are able to demonstrate the use of technology for building and delivering stable, performant and reusable services. The end result is that the individuals of Enterprise Architecture Group are openly invited to the table for consultations and recommendations.


I would love to hear of other organizational patterns/ formats that have enabled implementation of SOA and EDA.

Thanks.
surekha -