Recently, I was brought in, at a
Fortune 500 organization, as an Enterprise Architect by their newly
established Enterprise Architecture practice. I was to work on a couple of
major initiatives. In the kick-off meeting, a Program Manager for one of
those initiatives raised this question - "We already have a couple of
architects working on this program. Why do I need a third one?". To be
fair, he wasn't resisting my presence. He simply wanted to know the value I was
going to add. It was a fair question, especially considering the fact that he
was indirectly paying for my role.
I am sure different flavors of this question (why does an organization need
Enterprise Architecture (EA) or what exactly is the role of an Enterprise
Architect etc.) have been asked in several other organizations and answered.
Here is my take on it:
One of the traits of a
well-designed application is the efficient handling of crosscutting
concerns. By efficient I mean the
application architecture/framework to handle bulk of the crosscutting concerns
(such as security, transaction management, logging etc.) and let the individual
services concentrate on the business logic. In this blog entry, I discuss one
such cross cutting concern and a way to handle it at the framework level.