Enterprise Architecture

Architecture is a high level view of a system in the context of its environment, dependencies and technology. Architecture describes structure, behavior, integration and aesthetics.

Architecture must be solid, useful and beautiful.

In HSD the Architecture View encompasses Enterprise, Solution and System Architecture.

Enterprise Architecture applies architecture principles and practices to guide organizations through the business, information, process, and technology changes necessary to execute their strategies

Enterprise architecture is focused on making technical decisions that shape the work of an organisation via constraining or directing Solution Architectures and System Architectures. Enterprise Architecture does not deliver a product but instead provides a context for architectural work within an organization that ensures product architectures are aligned to Strategic Goals.

Enterprise Architecture is best defined as a set of architectural standards, decisions and common services. Having an understanding of Enterprise Architecture is necessary to help focus the Portfolio and reach the Portfolio Scoped Milestone. We have seen many organizations struggle to size their portfolios in an architectural vacuum. Estimations, guesses at the best of times, are particularly hard outside of meaningful architectural context.

The Portfolio and Enterprise Architecture have a bit of a circular relationship in that Enterprise Architecture is necessary to qualify the scope of the Portfolio, but Portfolio Requests may change the Enterprise Architecture, and the evolution of various systems and solutions over time also change the Enterprise Architecture. This circular relationship must be accepted, any Enterprise Architecture that doesn’t change is most likely incorrect.

Although standards and organization wide decisions can aid communication and alignment within an organization they can also inhibit creativity if there are too many rules to follow, and they are too formally applied. In our experience standards chosen by non-technical Business Leaders often have detrimental effects on development efficiency. We recommend that architectural decisions are evidence based and are made by people who are active practitioners. Architectural decisions must be made by those technically skilled enough to understand the advantages and disadvantages. Business Leaders are not expected to know everything and must not feel threatened by technical specialists. A strong Leader delegates decisions to those best suited to make them. If an organization does not trust its technical experts to make technical decisions it is unlikely to succeed and will undoubtedly diminish motivation amongst the technical community.

Enterprise Architecture often has a poor reputation in many organizations as being something that consultants have sold, resulting in many models in expensive tools and extensive documentation that no one uses. Canonical data models that involve many effort-months of meetings to agree that aren’t useful in software design are a poor substitute for real Enterprise Architecture.

Good Enterprise Architecture makes it easier to make new products by providing common starting points, technical direction, useful infrastructure and tooling as well as common organization-wide mechanisms such as authentication/logging etc.
Importantly Enterprise Architecture must not constrain innovative/inventive work, in terms of the Commoditization Scale although such work should be informed by EA to avoid too much technical divergence.
Many organizations struggle to “pull through” work from their research areas into specialist/mainstream development because of a lack of common technology stacks, languages etc. Where a specific technology is used for good reasons in innovation work, such decisions should not be constrained. However, if there is no technical reason to choose one technology over another then the one that is easiest for the rest of the organizations should be chosen.

Enterprise Architectural Standards

Standards will be those adopted by the organization to guide architectural and development work, standards need to be explained in terms of the types of development they are suitable for. Strongly engineering standard architectural patterns and mechanisms may be desirable for complicated work (including many systems of systems architectures) but is unlikely to be appropriate for innovative research and high complexity work. Innovative work needs to experiment with new ways of doing things and high complexity work needs to architect for change, not stable structures.
Typical Enterprise Architecture standards might include:
  • Standard Architectural nomenclature (e.g. System, Solution and Enterprise terminology)
  • Standard Architectural patterns (e.g. authentication, elasticity, logging, error handling)
  • Enterprise business data models
  • Development Standards (code standards, design standards)
  • Development Tools and Environments (e.g. continuous integration, source code management)
  • Common technology, hosting and deployment stacks
  • Technical Direction (e.g. use of standard ubiquitous technology, open interfaces, cloud based architectures, languages, technologies, technical practices)

Enterprise Architectural Decisions

Architectural decisions influence, or even direct, technical decision making in Solution and System Architectures. Not making these decisions at an Enterprise level can lead to technology diversification making long term support, licensing and maintenance expensive or even impossible. Many organizations will rightly choose not to use homogenous technology stacks throughout their enterprise, however, explicitly choosing which technologies should be used where is still necessary.
  • Choice of technology stack (e.g. persistency technologies, languages, development frameworks)
  • Choice of development tool chains (e.g. IDEs, source code management, collaboration tools, build tools, deployment tools)
  • Long-term architectural road maps (e.g. to migrate from decaying platforms to newer alternatives, gradual adoption of a new data interchange standard, cloud adoption, paradigm changes etc.)

Enterprise Architectural Services

Enterprise Architectural Services are common corporate services that Solution and System Architectures can make use of. Establishing enterprise reuse can be a misleading goal leading to large enterprise frameworks which become a heavy technical debt on any new endeavor but highly atomic services, with low dependencies, that are truly generic in the organization may be useful.

Enterprise Architecture Services take standards or decisions and actually build them. Providing working starting points, technology stacks or working functionality to new pieces of work to speed up their development. EA services should be automatically metricated where possible to ensure that they remain useful.

Examples of typical Enterprise Architecture services include:

  • Common authentication and authorization services
  • Common data models, formats or containers
  • Common platform configurations for development, hosting or operational use
  • Common messaging infrastructure
  • Common audit and logging services
  • Common environmental instantiation services (i.e. API based provisioning)

Common services like these are best described as Architectural Mechanisms, where they don’t exist as part of Enterprise Architecture they may often need to be created as part of a Solution Architecture or even a System Architecture. However, if left to System Architecture there is a high probability that each piece of work will duplicate mechanisms, wasting effort.

A Word of Warning

Enterprise Architecture is aimed at enhancing the efficiency of development in an organization but, all too often, becomes a source of impedance to development teams and organizational business agility. This can be especially true in terms of Enterprise Architecture stifling technical motivation, research and innovative experimentation. Enterprise Architecture needs to be as lightweight as possible, decided on by active technical practitioners and open to continuous challenge and improvement. We recommend quarterly (if not continuously) reviewing Enterprise Architecture for appropriateness, efficiency and alignment to strategy.
We strongly recommend that anyone involved in making architectural decisions is able to spend time working on real projects, building real software. Technical skills decay, and as the industry relentlessly progresses the expert coder of today quickly becomes the dinosaur of tomorrow. Mastery, as discussed in the People view, requires practice.
We recommend that technical leaders sit in on retrospectives and architectural show and tell sessions on other people’s projects to keep well informed of the breadth of technical diversity in an organization. Exposing technical decisions help everyone improve. There is no shame in not knowing the answer, but there is shame in pretending to know and deceiving an organization.
As we mentioned in the Architecture View, architecture must be solid, useful and beautiful. In Enterprise Architecture terms that means it must be:
  • Solid – Enterprise Architecture needs to be stable and yet current. It must be reliable and logically defensible.
  • Useful – If it’s not useful, retire it immediately. It must be lightweight and simple to use.
  • Beautiful – Good architecture is elegant and adds beauty to a solution, without being overly clever. Architecture is there to simplify the complex.