Enterprise Architecture

Enterprise Architecture centers around the design, planning implementation and maintenace of IT systems commonly found in large corporate environments. Availability, uptime and data bandwith are key concerns.

Common Architecture Patterns

In an fast moving technical landscape it is natural to be influenced by the latest innovative trends in systems design and implementation and the temptation is then to use these models without fully evaluating their suitability or other available options.

The latest designs do bring interesting benefits and opportunities - best exploited with full knowledge of some less apparent limitations and by undestanding how these models fit in with the needs of the business and how they can combine and work with older and more traditional models.

MicroServices

Highly scalable architecture based on many independent services

Highly scalable and flexible architecture relying on separately deployable, bounded contexts of independent units handling requests through a common API layer. Increasingly popular with the advent of cloud-based computing solutions as they fit well with 'elastic' computation and 'on demand' resource allocation. Can be inefficient in terms of performance to resource ratio because of the decorellation of components and associated intercommunication. Also be complex to deploy and manage, and the overall cost associated with the total solution is often surprisingly high.

Service-Based Architecture

Independently deployable services with common data layer

Typically less 'fine-grained' than a microservices architecture with bounded 'units' of independently deployable services with a commmon, shared, data layer. This architecture can be seen as a transition between a 'monolith' with a consolidated data store and a 'pure microservices' model with total compartmentalization of data and services. The interaction with client requests is still separated via a common UI (User Interface) layer providing a similar abstraction model as with microservices. Flexible and Scalability are typically less that with microservices, however there can be improvement in terms of overall cost and general performance of the solution.

Layered Architecture

Common multi-tier Architecture pattern

Traditionally also know as multi-tier Architecture - this is a common pattern dating back to the early days of client-server systems devlopment and larger scale software programs. The focus is on separation of the functional layers of the solution and isolation from other layers via interfaces. Although supplemented by more recent architecture styles like Microservices at the Enterprise level - the layered model is still omnipresent in many areas of IT and still defines the way underlying services like networking and telecommunications are handled.

Integration Bus

Integration Architecture based on publish-subscribe model

Also referred to as Pub-Sub (publish subscribe) or Message Broker architecture this is commonly used for integrating between Enterpise systems within larger extended environment. Components interact via a common message bus or broker usually based on queues which are indepenently published and subscribed to via 'adapters' or 'integraton agents'. Advantages are a natural decoupling of components and the ability to integrate new functionality without affecting exisiting infrastructure. Testing of the overall solution can be challenging however.

PipeLine Architecture

Data processing architecture based on flow and operations

Common architecture pattern in many recent AI and big data processing frameworks such as Apache Spark and TensorFlow. Based on the concept of a data 'pipe' flowing in a single direction with individual 'filters' operating independently on their inputs and returning the output to the 'pipe' for further processing or consumption downstream. In an enterprise setting this model can be naturally integrated into other messaging 'bus' architectures for processing of information between the central bus / broker and the producers / consumers.

There are several existing methodologies for implementing and managing Enterprise Architecture - some of the better known are the TOGAF^® (The Open Group Architecture Framework) specification proposed by The Open Group consortium, and the Zachman Framework for Enterprise Architecture ^™ proposed by John Zachman and now termed as an 'Enterprise Ontology^™' for categorising elements and assets of Enterprise Architecture.

While methodologies and frameworks may differ in details and even aims, what they share is formalizing the process of systems design and implementation on a large scale within complex organisational structures over an ongoing period of time.

The ongoing time element is a crucial factor here, although ironically this is sometimes overlooked. I would posit that the evolution of the system over time is the fundamental driver for the development of formalised Systems Architecture - it is at least as important as organisational complexity.

This continuity concept is built in to frameworks like TOGAF^® and is fundamental to the whole concept of Systems Architecture - namely that systems constantly evolve and are in a state of permanent flux and change and that managing this change is key.

So the real value in well designed Enterprise Architecture is similar to lower level software Architecture - it is the flexibility and ease with which the system can evolve continually over time rather than the specific cost / benefit value of a single iteration.