Many organizations, as they evolve, find themselves in a situation when they recognize that they must take a more proactive and forward-thinking approach to how they deliver value. Often, it involves organizational change and deliberate effort to transform the organization. These are often the times when Enterprise Architecture (EA) function is called into action.
Enterprise Architecture Principles are often one of the first things to be delivered by the EA organization and for a good reason. EA Principles are a way to set the foundation for everything else that EA does and to set the tone for the rest of the enterprise served by EA.
EA Principles are high level guidelines that aim to help the enterprise make decisions by highlighting preferred choices, preferred approaches and considerations for designing information systems. They are not hard fast rules, standards or even policies. They are not strategies, plans or promises of what will be done. However, for all the things that they are not, EA Principles attempt to steer the design of systems in the direction that allows more efficient realization of business and IT goals. You may have heard of EA Principles that promote reuse of components, call for interoperability or ask for more sensible approach to deciding when to build or buy. Perhaps you heard of principles that put emphasis on disciplined data management or security. Regardless of what set of EA Principles your organization adopts, it is important to recognize that those principles do not necessarily mean that everything will be done differently from now on. In fact, EA Principles codify the good behaviors already being practiced. In doing so they provide the acknowledgment that the ongoing transformation does not intend to turn everything on its head. Where there are gaps or changes in approach are needed, the EA Principles provide the first step in the introduction of concrete change measures.
A common misconception about EA Principles is that they are just rules for Architects. EA Principles are for everybody who is involved in any decision about systems that function in the enterprise. Decisions that affect enterprise systems often start as early as ideation and prioritization and continue through the entire solution delivery life-cycle. As they get involved, Business Analysts, Architects, Designers, Developers, QAs, Security experts, DBAs can all find a principle or its element that is very much applicable to their jobs. Take a principle that promotes reuse. It can apply to business processes, system components, blocks of code, test cases, data stores etc. The key is to stop and think what each EA Principle means to you as you perform your function.
Change is hard and for a large organization it is even harder. Large organizations don’t get big overnight. As they grow, they develop certain philosophy, certain habits and certain culture. Those are the things that make the organization what it is and often fuel its success. When change is needed, it is imperative to preserve what is valuable and only disrupt the areas where the course correction is needed.
As I stated earlier, EA Principles are not meant to be prescriptive – they guide but they don’t dictate. They are meant to be applied but their application may take a different form depending on where and who applies them. By intentionally keeping EA Principles at high level, leaving some room for interpretation, and by providing hints on how they can manifest themselves, we help individuals to internalize them. We create a sense of common direction and ownership of system decisions made at every level. In other words, we are bending the culture towards the desired change instead of imposing that change.
While instrumental in affecting the organization’s culture, EA Principles are at the heart of everything the EA organization does. They must be in place first because in order to define standards, codify best patterns and practices, define architecture processes we must have some foundation to build on. In any case, we will never have standards or patterns for everything. Frankly, we don’t want to. If we did, then we would create overly bureaucratic and rigid structure that finds it very had to innovate and adapt to change. In that context, EA Principles usher in allowing for flexibility where standards and hard-fast rules are not needed or simply not yet defined. They allow for that flexibility while providing the guardrails that force the decision makers to stay within the acceptable spectrum of solutions.
This last point has a lot of implications for Architecture Governance. Business and IT leaders ask for Architecture Governance very quickly after the EA function is established. It is understandable because it reflects the desire to get the architecture under control and what better way to do it than through set of processes and tools. But wait, wait, …how do you govern without the laws? If the rules are unknown then how can we expect them to be followed? EA Principles are not rules, laws or policies. However, they are something to point at when reviewing solutions and making system decisions. They are a prerequisite to successful Architecture Governance and one of the foundational elements of a successful Enterprise Architecture function.