Enterprise Architecture Macro
Enterprise Architecture Macro
The big picture of EA
Enterprise: The whole of a business, company, corporation…
Architecture: The classical consideration of a structure, and its constituent parts, and the parts relationship to one another.
That aught to clear things up. In all of my years working in the profession of Enterprise Architecture (EA) for a large tech company, toiling on international standards, and teaching hundreds of Enterprise Architects, the question of what Enterprise Architecture is was sure to start an intense discussion. So my definition is practice based. EA bent the heads of technical leaders who had made their careers with technical expertise, to an artistic consideration of where technology, business, and people join.
Over the years I have been asked one question often: “Our EA practice is starting, what should we do?” And here is my answer. There are two things that need to be accomplished at a broad level:
Put the enterprise’s treasure where its heart is.
Align the results of the architecture work with the budget cycle.
Every company was started for a reason. The founders had an idea about how something could be done better through innovation. What that something is can be found in the elevator pitch you give at a social gathering when asked what your company does. Yet every year at budget allocation time, money and people are divided up for projects to redo or remake parts of the business that have no, and I mean NO, connection to that core business. This is true particularly if the company has been in existence for a while. These diversions of hard earned capital are often justified by the “but we’re different” bias, or the “we’ve always done it this way” bias.
So the first job when you come in as Chief Enterprise Architect, or something similar, is to pare down and eventually halt the bleeding of money away from the core business. The next cycle for each function that is not core is to instantiate standard business processes (see APQC (American Productivity & Quality Center)) and packaged software or outsource solutions that will support them. Put your logo in that software package and do no other alterations. Gradually focus the money the company spends on its core business, and innovating on that core business, because I guarantee you that a three person startup team is aiming their project at your company .
The second job, and it’s necessary to get the first job done, is to discover and map the real budget process cycle and who the players (stakeholders) are. Your job is to deliver the information needed to help the decisions at each stage of the budget year, when that decision is being made. For example, one company I know had a “Spring Plan” and a “Fall Plan”. The Spring Plan gathered the next year’s budget requests, there was a period of research and then the Fall Plan finalized the budget for the following fiscal year. Find each stakeholder, determine what information they need by a deadline, and count backwards the amount of time needed to create the architecture work for that decision point. This will set the cycle of architecture work for the team.
Do not be late with the information. If you are late, keep the information to yourself, or at most, deliver any critical discovery verbally. Your stakeholders may have fiduciary responsibility to the company, and if you dump new information in writing to a principal decision maker after their decision, then a legal argument can be made that critical company decisions were made without due diligence. This could be a bad thing.
Each EA practice should operate as its own company in a company. Your output is a service, actionable information, not an architecture artifact. You need to make a mafia offer to the decision making principals about delivery of the two outcomes I described, so that you have a defense from being pulled into a meeting on how to rewrite the payroll application for the fifth time. But more on this in another post.