My view of enterprise architecture holds that every architectural decision or action must be driven by a business need. A business need can be strategic, tactical, or risk-mitigating. Unless the architect can explain his actions in terms of why it is good for the business, he should not be pursuing that action.
I posted a quick entry on the BDEA Blog in 2016 in response to requests for Enterprise Architecture principles. This page is a formalization of that post. I have added several points that I consider useful or clarifying. I will probably make further changes to this page so check back often. I have started expanding on my ideas so look for the (more) links spread throughout the points that lead to pages where I do that.
Here are the Epignosis Business-driven Enterprise Architecture Principles. I really wanted to call them the Ten Commandments of BDEA and put an image of the tablets on this page. Then I thought that at least one new principle might emerge and that would mess up the entire theme. So, we’ll just go with Business-driven Enterprise Architecture Principles.
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. (more)
Nothing matters more than how the Enterprise Architecture supports the business
The Enterprise Architect must understand what the business is trying to do and what needs to be done to support it. The Benefit Ratio, Benefits gained / Costs Expended, should be a really big number. Benefits are gained by the business. Costs are expended by everyone in the organization and have initial and ongoing components. These measures can be total or marginal. Benefits are generally overstated and costs are generally understated. Be brutally honest in this analysis. If metrics are in place prior to changes being made, they can be checked afterward to determine the efficacy of the changes. If no metrics exist, they should be established and implemented as part of the change project. Make sure both benefit and cost sides are audited afterwards to ensure the assumptions were correct. (more)
If something is defined more than once, it’s not well defined
There should be only one definition for a process, one implementation of an application that supports it, and one definition for the data element that is used in it. It’s easy to maintain one set of rules. It’s really hard to keep multiple implementations of the same rule set in sync. This applies to systems and to documentation. This does not mean you can’t have multiple instances of the same implementation.
Regardless of what your enterprise does, it can be distilled to a single set of essential processes
I call this single set of essential processes the Factory. The Factory comprises Core processes and is supported by other processes called Safeguards and Exceptions. Core processes are the activities essential to the business’ operations. Safeguard processes are necessary to protect the Factory (e.g. Pre-edit, Reconciliation, Audit, and Security and Enterprise Architecture). Exception processes allow transactions that can’t worked in the Factory to be completed or made so they can reenter the Factory. The Factory should always be improved, Safeguards should always be strengthened, and the need for Exceptions should always be reduced.
Talent always wins over experience
And talent is expensive. The uber-talented can grasp and solve many problems in many domains. They are really expensive. There is only so much money available to hire the talent you need. You want the best talent you can get. Talent is measured by the number and depth of the skills possessed by a specific person that can be applied to the problems you have. Experience is a measure of survival. Ask any coach. Someone you find talented may merely seem experienced to a manager with different problems. You want talented people who will stay with you because they are happy and well compensated. It’s true whether we’re talking about technical people or business people. Some you can afford to hire. Some you can only afford to rent for a finite period of time. Understand the difference and spend wisely.
Your technology stack should be as narrow as possible
There are multiple business reasons for this.
It’s easier to keep track of a smaller number of technologies than a larger number
Outdated technologies are the second largest set of attack surfaces for infiltrators. You need to understand everything running in your environment so you can monitor for vulnerabilities. You then need to patch for them. Cleaning up everything with one patch is easier than cleaning one thing with one patch and the same thing in a different technology with another.
You need talent to manage your business and your systems
Budgets are not inexhaustible so it’s better to get great expertise and coverage for fewer processes and technologies with the talented people you can afford than to have to scrimp on expertise and coverage for many technologies because you can’t afford enough talented people. Getting a greater number of less talented people is not a good trade.
Security is not a bolt-on
Everyone worries about the functional requirements. The business generally only wants to pay for implementing their functional requirements. At the end of the project, or worse after you’ve been infiltrated, people start to worry about security and then try to bolt it on to the existing problem process or application. Think about security at the beginning and design with those requirements in mind. The entire enterprise should understand the necessity of good security. Poor security habits by business (and technical) people are the largest infiltration attack surface. I have my own recommendation for a security mindset. Find it here.
Technology decisions do not drive business decisions
With everything I’ve already said, you can’t make the business sub optimize in order to meet your technical needs. If their best solution requires you to expand your technology stack, you need to tell them how that increases the technical staffing needs and operating costs of the enterprise. This should be reflected in the Benefit/Cost ratio discussed above. If you increase operating costs enough, the benefits get diluted and maybe what was initially the second choice due to lower benefits now becomes the first choice because it has a higher Benefit Ratio due to a lower total cost of ownership.
Templates are too specific and Frameworks are too general to be useful
There are several reasons for this.
Templates don’t allow you to adequately define your business situation
Since each business situation is unique, it’s really hard to borrow someone else’s template to use for your situation. You will find that you have to make some modification to every template in order to make it useful.
Frameworks are really just suggestions
They say you can do this…or not. How is that helpful? You could just go through the entire framework and say, “Or not” and be done with it.
Frameworks lead to ambiguity rather than clear thought
Just go look at any public forum that tries to discuss Enterprise Architecture and the “supporting” frameworks. I read instances where two people using the same framework can’t agree on what a particular model is saying or on the definition of a particular idea. We still don’t have a good definition of Enterprise Architecture or for where the architecture function belongs in the enterprise.
You don’t need an Enterprise Architecture; you need to understand the one you have
Then you need to adjust it to meet the needs of your new business realities.
Most enterprise structures predate the Information era
That means they evolved without the knowledge of how connectivity makes everything different. They can’t cope with the exponential jump in available information and how it must be used to compete. They can’t cope with the demands of securing their information to protect their competitive advantage and their customers’ privacy. In practically every case, they don’t know how or where they are vulnerable to loss.
Too many people think that Enterprise Architecture is a new place
The problem with moving to a new place is you have to do something with your existing stuff. You either need to move it too or get rid of it. You can’t keep it where it is. It you do then you have only made your environment more complex and more expensive. Your current Benefit Ratio is your overall profit ratio or similar metric. It must be at this macro level, it’s an Enterprise Architecture. The object is to make your Benefit Ratio bigger.
Models do not contain enough information to explain reality
The reality of the Enterprise Architect is that he must have information about the business that is useful to management and that other managers can’t easily obtain or distill. Models are incomplete by definition. This makes them useless for risk mitigation purposes. Risk mitigation is about details of the real environment. Stop wasting time building and arguing over models. Spend that time understanding what you have so you can make it better.