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.
Enterprise Architectural Standards
- 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
- 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
- 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.