A Summary of Architecture Work

What is architecture?

Definitions abound! But are often more complicated than they are helpful. Usually, there are a few common themes where architecture exists to:

• Bring structure, making things easier to understand by showing how larger and more complex things are comprised of smaller and simpler things
•  Brings the structure to life by showing how things interact, describing X talking to Y and Z and passing ABC information to achieve DEF for the HIJ user
•  Brings a repeatable method for designing and building things that increases the chances of the customer being happy for a longer time
• Balances the focus of delivery teams across functional (what it does) and non-functional aspects (performance, scalability, security, resilience, maintainability, future changeability)

What is in an Architecture?

Architecture is a big and complex thing, likely to include:

• A lot of text explaining why something is required, how it is to be designed, built and run, how it will work, and how it supports the customer's long-term goals
• Models and diagrams bring the text to life, describing the structure, composition and interaction of components
• Plans, blueprints and specifications for building the systems the architecture describes
• Standards, guidelines, principles and constraints describing how the architecture was constructed, and how implementation projects should proceed
•  An AS-IS view showing what is there today, a TO-BE view describing what will eventually be there, and a roadmap describing the steps needed to get from the as-is to the to-be; each of these steps is likely to be realized by a project and is often described as a “transition architecture”
• Broad coverage: an architecture isn't just about technology, it should also describe what the end-users are actually trying to achieve, and why — independent of any IT systems that might be involved

It takes a lot of effort to create and maintain the architecture and that effort tends to come from expensive people, so it is very important that effort is well spent, and that architectures only go into the level of detail required: hence each architecture should include a justification for its existence, outlining what level of detail is required, and how/if the architecture will be maintained.

What kinds of Architecture are there?

Part of the problem with understanding what architecture is, is that there are so many kinds of architecture, and each one is different:

• An Enterprise Architecture defines a long-term strategy for a company, and a roadmap for implementing it over the next 5–10 years. It’s very broad (covers everything) but not very deep (not much detail), and there is usually only one, covering the whole company (or at least a whole region or division of that company).
• A Solutions Architecture defines how each stop on the strategic roadmap is implemented by creating or changing individual systems. It has a shorter term focus (6–18 months), less breadth and more depth than an enterprise architecture, and there will usually be many solutions architectures (i.e. projects) in flight at once. Once the solution is implemented the architecture usually ceases to have relevance, but the product architectures it touched along the way, will be its lasting legacy.
• A System or Product Architecture describes how that single system works, and what it talks to. It will have an ongoing lifecycle (i.e., lasts as long as the product exists) and will evolve over time as many different solutions architectures (i.e. projects) request changes to the product. It is likely to have low breadth, but high depth, and there will be many product architectures in a company: as many as there are products. The system architecture is likely to be a wrapper for software and infrastructure architectures, and may reference a Platform Architecture if the System is deployed to a platform rather than directly to the Infrastructure.
• A Software Architecture is a specialized part of system architecture, that focuses on the application code
• An Infrastructure Architecture is a specialized part of system architecture, that focuses on the infrastructure (servers, storage, networking) — and which depending on deployment choices can become a cloud infrastructure architecture, a hybrid-infrastructure architecture, or any number of on-premises infrastructure architectures
• A Platform Architecture is a specialized form of system architecture, that describes how a set of shared services (the platform) are implemented, and how they are consumed by other systems (i.e. those systems using or hosted on the platform). A platform is likely to be a combination of hosting services (i.e. servers, virtual machines, Kubernetes), storage and networking, monitoring, backup & recovery, and deployment.
• A Reference Architecture is a generic form of any of the other architectures, acting as an example of what should be covered, how something should work, or providing a taxonomy (a naming convention and classification scheme)
• There are many other forms of specialized architecture: Security, Financial, Test, User-Interface, Monitoring, etc.

How do all these architectures fit together?

• There should be a single enterprise architecture, that describes the company today (the AS-IS), the desired end-state (the TO-BE) and a 5-to-10-year roadmap explaining how to get to that end-state.
• Each of the steps on the enterprise roadmap will be realized by a project, and each project will have its own solutions architecture, describing what that project is delivering.
• Each project will require new business and IT systems to be created, and existing ones to be changed or disposed of. Each of these systems will have its own product architecture describing how it works and what it talks to.
• Each of those products will have its own software architecture.

Depending on how its deployed, the product may have its own infrastructure architecture, or it may be deployed onto a shared platform, if it’s the latter, that platform will have a platform architecture of its own, with accompanying software and infrastructure architectures.

Avoiding duplication

As there are many kinds of architecture, there is a high risk of duplicating content across multiple architectures, in architectures contradicting each other, in everything getting stale (out of date, outright incorrect) very quickly, and in the architectures bearing no resemblance to what projects are building / operations are running. There are no silver bullets to solve these problems, but some techniques have emerged:

• Go into as little depth as possible, while keeping the architectures feasible. More detail = more maintenance overhead and more risk that maintenance/alignment won't happen, so try to ensure the architectures only contain the things they need to.
• Frequent 360-degree communication and collaboration: the enterprise architect must be talking with the solution and product architects, reviewing their architectures and ensuring they are still in alignment. Architects must also be talking to delivery and operations to ensure they understand how well their architectures are panning out in the real world
• Retiring (ie archiving/flagging as no longer relevant) architectures as soon as possible. For example, retiring the solutions architecture as soon as it is delivered, leaving the product architectures to be evolved by future solutions.

Much of Waterfall

It’s also quite likely some agile folks will see the above as the worst examples of top-down thinking and waterfall planning. But agile and architecture should be complimentary. Enterprise Architectures are there to provide the high-level structure and inform long-term business strategy; Solutions Architectures are there to describe how each step in Enterprise Roadmap is to be realized at a medium level of detail, and Software Architectures are there to facilitate agile software development and fill in the low-level details needed to build and run the IT systems introduced in the Solutions Architecture.

To get long-term success, the enterprise, solutions and software Architecture will need to work with the engineers and everyone should be pulling in the same direction, i.e., the architecture has to be useful to the engineers, not a mocked document sat on a shelf. Hence engineers are critical stakeholders in the construction of the architecture.

The many types of architecture will be covered in more detail later, for now, it is enough to remember every architecture is different but there are some common elements that every architecture must deal with, and top of that list is managing complexity

Managing Complexity:

To keep architectures manageable, it is common to separate them into chunks, which include:

• Domains, grouping a set of related concerns and allowing a consumer of the architecture to focus on one concern at a time, for example, business, information, IT Systems etc.
• Layers, or levels of abstraction, allow consumers to focus on “why”, “what”, “how”, and “with what”
• Cross-references, binding and indexing the domains and layers together into a coherent whole — so if someone asks, “why is this thing here?” the logic can be traced back to a good reason
• RAIDD (Risks, Issues, Assumptions, Decisions, and Dependencies) help record how we got here, and what we were worried about

Architecture Domains

Architecture Domains include:

• Business Architecture — describing what business problems the architecture is trying to solve: who are the users, and what do they want to achieve (regardless of what the IT services get provisioned) — e.g. for Prime Video the business architecture is “people anywhere want to consume movies and TV shows”
• Information Architecture — describing what information and data is needed, and how/where it is created, modified and deleted — e.g. for Prime Video the Information architecture describes the customers, their subscription packages & bills, the shows, and the statistics on who watched what”
• IT Systems Architecture — describing what applications must be created to realize the Business Architecture, and how those applications must communicate — e.g. for Prime Video this describes the mobile app, the website, the back-end streaming services, the billing engine, the helpdesk.
• Technology Architecture — describing what hardware and software is required to run the IT Systems: what servers, storage, networking.
• Security Architecture — that describes the confidentiality, availability, and integrity controls, are required — e.g. for Prime Video how are user accounts protected from hackers, what DRM is on the movies, and how do we ensure Prime Video services are always available for use.
• Governance Architecture — describing the operational controls allowing us to be certain the service is working: the monitoring & auditing, the rate-limiting / throttling, and the fraud detection.

Architecture Layers

And each Architecture is going to have several layers — potentially associated with phases the architecture goes through while it is being created

• Contextual — explaining the “why” and laying out the ground rules for this architecture: standards, principles, tech policy, constraints
• Conceptual — explaining the “what do we need” to realize the architecture; but not yet attempting to understand how we realize it — the brainstorming phase
• Logical — explaining the “how do we realize” the conceptual architecture, grouping all the requirements into a simplified set of logical “chunks” that might eventually become IT systems, or purchased as COTS packages and SaaS services
• Physical — explaining the “with what will we achieve this” mapping the logical components into things we will actually build or purchase as COTS packages and SaaS services.

Models

Each of the domains and the conceptual, logical and physical layers will be comprised of architecture models and explanatory text like the decision log.

The models can include:

• Lists of things: like business services, applications, and servers, including descriptions of those things (why they exist, what they do, who uses them) and architecturally significant functional and non-functional requirements (clients must provide an OAUTH2 key, backups must be taken every 4 hours, service must respond in under 3 seconds, and support 99.99% uptime)
• The composition of things: e.g. that “The Ordering System” is comprised of services handling “create order”, “approve order”, “send order”, “validate order has been delivered”, “send order to billing system”
• The interactions between things: e.g. that the Ordering System passes Order Information to the Billing System, which then passes Account Updates to the Finance System
• Service levels for interactions e.g. the Ordering System can pass the Billing System up to 10 transactions per-second, each of which can be 5kb in size, and each request must contain a valid OAUTH2 authentication token

Each architecture role will have a preferred way of creating architecture diagrams. For example, an enterprise or solutions architect may prefer to use The Open Group - TOGAF method for creating models, and their Archimate diagramming language, whereas a Software Architect may prefer UML or C4 method.

In many ways the actual method being used to develop the architecture, and the diagramming styles don’t matter, so long as all consumers understand the method and can work with the Artefacts.

Cross References

There are many cross references within an architecture — these hold the individual architecture together, and include elements like:

• Business to Information: what information is created or processed by each part of the business?
• Business to IT Systems: which parts of the business process does each IT system support?
• IT System to Technology: what infrastructure do the IT Systems need to be deployed onto?
• Physical to Logical: how do these sets of concerns actually get realised?
• Contextual to Conceptual: why do these concerns matter / what part of the strategy are they here to deliver?

These cross-references can navigate the architecture, answering questions like “who cares if the server 123 goes down?” Cross-referencing from server 123 (Technology Domain) to the email system (IT System Domain), then from the email system to the billing process that uses it (Business Domain) to the realization that if server 123 goes down, we can no longer bill clients — therefore server 123 needs to be highly available and monitored properly.

There are also cross-references between architectures — which are vital for ensuring a system architecture correctly realises the vision of a solutions architecture, and that the solutions architecture is aligned with the enterprise strategy:

• The solution to System: this solution architecture changes those 3 product architectures
• Enterprise to Solution: this step in the enterprise architecture roadmap is realised by the solutions architecture
• System to Platform: this system is deployed on that platform

Therefore, the navigations can also map a Platform Architecture onto several System Architectures, then go from those System Architectures to the steps on the Enterprise Roadmap they realise, to understand how a single Platform supports the Enterprise Architecture, and how that Platform will evolve as multiple Solutions change it.

RAID Logs

These are about project and stakeholder management — a vital part of the architecture role. They help record the things we are worried about, and the actions we are taking to make those things less worrying. They probably form the majority of our day-to-day actions.

• Risks — bad things that might happen, that we need to monitor, make less likely, and add mitigation so if they do happen, it doesn’t hurt as much
• Issues — bad things that have happened, that we now need to make easier to live with
• Assumptions — things we have guessed at, so that we can carry on and make progress, but that we need to keep an eye on, and influence so they are more likely to go the way we hope, or that if they don’t, it won’t hurt so much
• Decisions — the things we chose to do, and wrote down to share with others, so everyone knows how and why we ended up where we did
• Dependencies — the external things we need to go our way, that we are tracking and working to make sure they go the way want or preparing in case they don’t so it doesn’t hurt so bad.

They might sound like a project manager job — but it is essential the architect is on top of this workload and is actively prioritizing the work to close down every open risk/issue/assumption/decision and dependency.

Enterprise Architecture

Comes from the idea that success requires everyone in the company to understand the mission: who the customer is, how we help them, why they would pick us, how we are different from all the other companies, and critically: ensuring everyone in the company is pulling in the same direction.

It is a top-down approach, meaning Enterprise Architects (actually management consultants), should be few in number and operating at the top of a company — at heads-of-division or board level. They are there to translate the company’s aspirational mission statement into a long-term strategy, ensure that strategy gets implemented through a series of projects, and ensure everyone in the company is bought into that strategy and those projects.

They will be dealing with a 5 to 10-year planning horizon, making very long-term decisions, or “the big bets” on which the company builds its future. They will spend a lot of time talking about contextual architecture (strategy, roadmaps, principles, constraints, tech policy) — the major concerns that guide everything a company does. They will also be very interested in the business architecture (i.e. “what the company does for its clients”), but relatively little time talking about technology architecture (i.e. what IT systems the company has). They definitely shouldn’t be down in the weeds of provisioning AWS infrastructure but could be guiding the decisions of whether the company uses AWS, Azure or GCP, and whether they will build cloud-native or cloud-hosted solutions.

Solution Architecture

If Enterprise Architecture is about corporate strategy and 5 to 10-year journeys, a Solutions Architecture is about taking one of the steps on that journey. A single solutions architecture is likely to touch several systems, and each of those systems will have its own software and infrastructure architectures.

As an example, a Walmart company might be selling products through a chain of shops but have identified, in its enterprise architecture, a need to compete with online retailers. A solution might be developed over several phases to establish that online presence as follows:

• MVP: an Alpha website enabling a small group of pre-selected customers to order a limited range of products and collect/pay at their nearest retail store
• Private Beta: expanding the product catalog, and allowing chosen users to create accounts, introduce a product reviews system, and allow home deliveries
• Public Beta: Allow any user to create an account, significantly expand product catalog, strengthen security controls, introduce promotions and marketing campaigns
• Full Service: Quality of service improvements

Each of those solution phases will require changes to existing systems and the introduction of new systems (i.e. updates/creation of those systems' product architectures)

Hence there is likely to be one solutions architecture that describes 4 phases, with each phase describing a high-level a set of changes to system architectures. Then a set of system architectures that describe how each of those systems changes at a high level of detail. In that sense, the solution architecture is providing a set of requirements for each of those ongoing product architectures, and those product architectures are what actually get realized by the engineers.

Alongside the solution architectures creating the online services, there are likely to be many other solutions in flight: expanding into a new geography, introducing a new product or service, migrating from an on-prem data centre to a cloud service, patching and upgrading applications, etc. and each of those solutions may also touch some of the same systems. So, it is important the system architectures can absorb changes from multiple solutions at once.

A table of contents for a typical solution is likely to include:

• What business problem does this solution solve, and for whom?
• How this solution supports the strategic vision?
• What systems does this solution depend upon?
• How does the solution’s data/users flow between those systems?
• What changes are required to those systems? Both functional (what must they allow users to do) and non-functional (volume of users, concurrent requests per-second, response times, authentication, availability, backup & recovery)
• How will the solution be implemented (what phases, what releases?)

System (Product) Architecture

A systems architecture describes how that single system works, who uses it / what business problem it solves, what it talks to, what data it creates, updates and deletes, what infrastructure it runs on, and what service levels it provides.

It is the highly detailed set of plans needed to build the system but isn’t necessarily going to go down to the lowest levels of details in all areas (separate software and infrastructure architectures are more likely to do that).

Unlike a solutions architecture, a systems architecture is going to be a very long-lived artifact surviving for the life of the system it describes and being changed by many different solutions. It might even be incorporating changes for several different solutions in a single release of the system.

A table of contents for a typical solution is likely to include:

• What business problem does this system solve, and for whom?
• What other systems does this one interact with: what is it dependent on / what is dependent on it?
• How this system supports the strategic vision, and complies with tech policy?
• How do any IT applications work, how are they realized, what components, COTS products and libraries are involved (perhaps going down to software design, perhaps referencing a separate software architecture)
• What infrastructure or platform services are consumed? What servers, storage, networking (perhaps referencing a separate infrastructure architecture)

Specific sections will cover the system’s functional requirements: such as: what does it do, how do data/users move within the system, and what is passed to/from other systems.

Other sections will cover the non-functional requirements:

• How is security handled: what authentication & authorisation, what encryption, what access roles, what auditing and non-repudiation, what firewalls and NACLs?
• How is monitoring and alerting handled, what log files are created & under what circumstances, how are incidents to be identified and fixed?
• How do users interact with the system (if via user interfaces, what accessibility needs must be met, such as screen-reader compliance)
• What performance and scalability is needed: volume of users, concurrent requests per-second, response times, message sizes, throttling, does load vary throughout the day?
• What availability is required (e.g. 09:00–17:00 Monday to Friday excluding public holidays, or 24x7x365 at 99.999%), and what failover, backup & recovery
• How will the system be implemented? What phases and releases will be needed? How is the system upgraded?
• What will the operations team need to do, and how will they do it: e.g. how do they troubleshoot the system, how do they patch/upgrade it?
• What housekeeping is in place (e.g. archiving log files, purging old data, restarting failed instances)
• Compliance requirements, such as how ISO27001 is evidenced,

And finally, other sections might cover delivery concerns: risks, issues and assumptions to be managed via project delivery and tested by the QA team. Dependencies on other teams, and implementation constraints.

Software Architecture

The software architecture is a specialized form of systems architecture, that focuses on the application code making up that system, and represents a common break point between the architectures using the enterprise style (i.e. Enterprise, Solutions and Systems architectures typically use TOGAF, IAF or Zachman) and those using specialist styles and constructs such as UML for software, or IDF for infrastructure.

The software architecture focuses on the code: how is it structured? What are the specific API constructs? What programming languages and frameworks are used? What versions of what libraries are used? How is the code compiled and how are CI/CD pipelines used to package, test and deploy the code? Hence, the breadth is relatively low: just the components within the architecture; but depth is much greater, with detailed designs often created within the software architecture — although not always by the software architect as detailed design should be owned and carried out by the entire engineering team, not just someone with an architect badge.

There will be some cross-over (or at least reference to) the system architecture, describing the business problem this system solves, for whom; dependencies to/from other systems, alignment with the strategic vision, and compliance with tech policy. However, the focus is at a much lower level of detail, suitable for the software engineers to implement, and the Quality Assurance to assemble tests.

The table of contents for the software architecture document is likely to be pretty similar to the systems architecture, but the focus is different. Everything is about the structure and functionality of the application code. Therefore the modeling will also be different, UML is more likely to be used (other styles are also available), and class diagrams and sequence diagrams show how the code is structured and how it interacts.

Infrastructure Architecture

The infrastructure architecture (like the software architecture) is a specialized form of systems architecture, that focuses on the computing (servers, storage, networking) required to host the application code. It’s also another a common break point between the architectures using the enterprise style (i.e. Archimate modeling) and specialist styles (i.e. AWS specific symbols and diagrams)

There will be some cross-over (or at least reference to) the system architecture, describing the business problem this system solves, for whom; dependencies to/from other systems, alignment with the strategic vision, and compliance with tech policy. However, the focus is at a lower level of detail with less breadth, suitable for the infrastructure engineers to implement, and the Quality Assurance to assemble tests.

There are a few different styles of infrastructure architecture:

• The legacy style of on-premises services built around mainframes (e.g. VME), midrange (e.g. AS/400, Power8), and proprietary compute (e.g. Solaris, AIX)
• The more recent on-premises styles using commodity compute (e.g. x86 blade servers) and virtualisation (e.g. VMWare) — potentially air-gapped from the cloud for security and compliance reasons
• The cloud hosted solutions, replicating the traditional style on AWS, Azure, GCP and OCI
• The cloud provider native solutions, replacing self-built infrastructure stacks (e.g. Oracle Databases, IBM MQs) with cloud SaaS/PaaS solutions (e.g. AuroraDB, SQS)
• The cloud provider agnostic solutions, swapping the SaaS/PaaS solutions for super portable and provider agnostic solutions like Kubernetes

Each style of infrastructure architecture will require a different set of specialist skills to realise.

• On-premises solutions require datacentre planning, taking into account physical space, power and cooling capacity, and the long lead times needed to order and rack/stack physical servers.
• VM based solutions require significant effort to be expended creating and supporting “standard stacks” containing the appropriate configuration of operating system, application servers, system management and monitoring agents, and the necessary configuration, patching and deployment processes.
• Cloud based solutions typically require more thought on how to secure the system from internet-based attacks, understanding how the services each cloud provider offers differ, and the capabilities needed to configure, scale, and automate their provisioning.
•  Platform based solutions are possible in the cloud and on-premises. In this scenario the code isn’t deployed directly to infrastructure, but to a shared hosting platform, such as VMWare or Kubernetes, and this shared platform provides a wide range of hosting services: storage, compute, scalability, monitoring, auto-recovery, release/deployment, and often many more.
• More complex and hybrid solutions where a single system is deployed across multiple cloud providers, or multiple styles of architecture (e.g on-premises AND cloud)

Other than that, the table of contents for the infrastructure architecture document is likely to be pretty similar to the systems architecture, but the focus is different: everything is about the “tin” necessary to host the application code and respond to changes in user volumes.

There will also need to be significant consideration given to failure scenarios: when the infra fails, really bad things happen: how can the application be expected to carry on when the network goes down, or the database becomes corrupt? This often requires the deployment of high-availability solutions such as additional servers, or even disaster recovery sites offering a complete clone of the infrastructure in alternative facilities that can automatically take over (probably) in the event the primary site suffers an outage. These scenarios are often very difficult to properly test, and such tests can often only reliably be carried out in the production environment — which does not often go down well with the end user.

Infrastructure Architecture concepts like High-Availability Clusters and Disaster Recovery highlight the need for collaboration between architects. Both software and infrastructure architectures must support the disaster recovery approach. The solutions architect must ensure the availability of one system is supported by the availability of its dependent systems. The choice of software components, infrastructure and cloud services must be supported by the technology policy/strategy maintained by the enterprise architects.

Platform Architecture

The platform architecture is a special kind of system architecture, where the user group isn’t the end-user interacting with the application, but one or more application development teams, who will be using the platform to host their applications.

The platform will be built around technologies like VMWare, or a Kubernetes distribution (OpenShift, EKS, Mirantis, etc) and will provide basic infrastructure services like compute storage and networking. But its benefits come from value-add services the application team can simply consumer (rather than building themselves) such as:

• Operations services like Monitoring, tracing & alerting, and dashboarding of system performance/capacity / uptime/usage, service patching/updating
• Deployment services like code releases, testing and roll-back
• Infrastructure services like automated and on-demand backup & recovery, automated scale in/out, self-heal, and storage replication and analysis (e.g. searching for PII and key-leaks)
• Application services like message queues, publish/subscribe notifications, analytics, task scheduling (e.g. house-keeping activities like purging data and archiving log files)
• Developer services like code repositories, task management, wikis, CI/CD
• Security services like authentication, authorization, encryption at rest and in-transit, key management, role-based access control, user-audit

Platform services are often generic, meaning they can be consumed simultaneously by many different application teams. The main use of platforms is to prevent the application developers from having to worry about “the tin”, meaning they can focus all their energy on serving their end-users.

Reference Architectures

Are a generic form of any of the other architectures, acting as an example of what should be covered, showing how something should work, and often providing reference models, such as a taxonomy (naming convention and classification scheme)

There are many others. The OpenGroup promotes the snappily titled Integrated Information Infrastructure Reference Model, and the AWS Well Architected Framework could be considered a collection of reference architectures for building effective architectures in the cloud.

 Conclusions

what architecture is, and introduced the common domains (business, information, IT systems and technology), the layers (contextual, conceptual, logical, physical) and the kinds of cross-references we do between layers, domains and architectures.

About Author

M Senthil Kumar is Program Head of Digital Solutions & Presales for Continental Europe at TechM. In his role, he is responsible for designing and architect digital solutions for large enterprises utilizing nextgen digital solutions with AI/NLP/ML/AR/VR/IoT/RFID/QR, etc. Spearheads Enterprise Architecture, carries 20 years' experience in IT infrastructure Service Strategy, Service Design, Services Support, Engineering, Systems and Software Architecture, Consulting, and Presales. Truly focused on customer service excellence, enabling continuous improvement by assessing and identifying customer business needs.

Disclaimer: The opinions expressed on this site are mine and do not represent my employers (past or present) or any other entity. I give no warranty or guarantee whatsoever regarding the accuracy, reliability, or completeness of the information provided on my article/website. I will not be liable to you under any circumstances for any loss or damage arising from your use of such information. Users are advised to check the accuracy of the information on this article/website.