Business-driven Enterprise Architecture Principle #1

Enterprise Architecture is a business discipline, not just a technical discipline

Everything is a business decision. The needs of the business drive every decision. Technology decisions must be presented as business decisions.

Refer to this prior post about how one practicing Enterprise Architect views a duality of talent need for Enterprise Architects to be successful.  My rebuttal to this point is that the Enterprise Architect doesn’t need to sell projects to the business leaders if he proposes projects that align with the business leaders’ existing plans.  The only way to do this is to be in the meetings or among the first recipients of the outcome of those meetings where these decisions are made.  This happens when the Enterprise Architect is viewed as someone having valuable input to the business decision-making process.

EA is a business discipline

I initially posed my BDEA Principles in this BDEA Blog post.  In it, I gave this example:

[The Enterprise Architect should approach a proposed project to remediate application atrophy/technical debt this way], we need to upgrade the technology in this system because the current technology has known security problems.  These problems are exposed on the public Internet so it’s only a matter of time before we are infiltrated if we have not been already.  The cost of a security breach is at least $300 per customer record lost.  We have n Customer records that could be exposed.  Then there are the costs of the bad publicity and loss of customer trust, and the time we will spend defending against lawsuits.  We have the following options at various price points…

When the Enterprise Architect frames the need for a project this way, he defines “why” this project is important to the business leaders in terms they most certainly understand. He has done the following things that he can use to compute the business benefit of the project:

Define the technical  problem in business terms

He has defined the technical problem in terms of business risk (e.g. the website will probably be infiltrated because of the known security holes in our system right now.)

Define as many known costs as possible

He can define the known cost of a security breach (e.g. cost per customer record lost times the number of customer records that could be exposed.)

identify other unknown, but estimable, costs that will follow

The marketing costs and loss of market opportunity from bad publicity and loss of customer trust.  The CEO will be looking to the CMO to estimate these costs.  The CMO can look at what’s happened to Target Corporation and its business leaders since they were breached.

The legal hit from customer lawsuits.  The CEO will be asking the CLO to estimate these costs.  Class action lawsuits are not fun and are very expensive.  There will be many people from the IT staff called to provide data to answer discovery requests and perhaps even to testify in court.  This takes a highly skilled and expensive resource away from normal duties upon which the business depends.

EA is not just a technical discipline

I don’t believe that the Enterprise Architect is the super-technician who is in charge of IT governance and systems design.  I do believe he needs to have enough technical skill to participate in the peer-review of any and all IT projects.  He needs to know the right questions to ask. Most of these questions focus on how the proposed implementations satisfy all of the business requirements, both functional and non-functional.

The problem with trying to be the super-technician is that you must keep up on every technology used in your IT shop.  This is an argument to keep your technology stack very narrow. I really don’t have the time or the inclination to try to keep up with everything at a detailed level.  But you know what?  There are people all over my IT shop who live and breathe certain technologies and development techniques and are thus so inclined.  They are also well aware of the standards required to make multi-tiered, composite systems work correctly.  I choose to leverage their knowledge and expertise so that I can concentrate on “big picture” stuff that matters to my business leaders.

Back to the story

Getting back to the technical debt story, the Enterprise Architect should discuss possible projects for upgrading those technologies that are vulnerable to attack.  He should work with this IT teams to establish the cost for each project option.  He should then compute the benefit ratio for each.  Finally, he should present the options with their benefit ratios to the business leaders and let them decide which project they want to buy.  The Enterprise Architect does not need to sell here.  But notice that I have always referred to options.  Never try to pitch a single option to your business leaders.  They always want to decide between two or more things if for no other reason than to keep you honest about presenting options that work for the business and not overblown projects that benefit the technologists more.