For those with a common sense approach to Information Technology, the need for architecture is a well-known fact with no question for its importance on any IT project. However, some organizations today expect their solution vendor to provide for the bulk of their architectural needs “behind the scenes”. This diminishes the perceived importance of a coherent architecture throughout the entire organization. Furthermore, it may also contribute to a systemic misconception of architecture that stems from all the way up to the CxO level.
Before diving into the various components for architecture and how they all tie together, consider a fictitious architecture-deficit organization running multiple IT systems for various purposes. Each system generally serves a business process and/or business unit, with each deployment being very focused and in an isolated environment specifically serving the needs of its business users. In so doing, these IT systems have been deployed without considering the overall business and technology strategy of the organization as a whole.
The outcome of a scenario is that you end up multiple systems having no unified integration, lacking a common technology platform and IT governance process. This creates a vacuum of end-to-end knowledge on all systems, higher maintenance costs, and a much lower ability for an organization to grow its IT footprint horizontally and vertically effectively and efficiently.
So, we come back to a fundamental question: why does architecture matter?
Architecture matters for the very same reasons that blueprints matter when building a house, or planning your financial future, or planning a journey across the Atlantic ocean by boat. As seen in the example above, architecture matters because without it, you end up with a uncontrollable and unmanageable IT footprint serving your business units and processes in an inflexible and often costly model.
Let’s not forget, for the eco-friendly side of us, in today’s eco-conscious society you can also see a need for good design and architecture to improve the efficiency of IT systems that consume power to process software programs and perform computations. A poorly designed piece of software or hardware can potentially compromise its carbon footprint, particularly on large-scale systems (think Google, Amazon, eBay etc.).
It comes down to planning – planning at a technology level. Without a good plan, you will never know where you need to go and how, and you will always encounter problems that will have you chasing your own tail for days/weeks on-end.
So, let’s start by examining some of the main components of architecture and their benefits from different perspectives.
Enterprise Architecture (EA)
MIT’s Center for Information Systems Research defines it best:
“Enterprise Architecture is the organizing logic for business processes and IT infrastructure reflecting the integration and standardization requirements of the firm’s operating model.”
Simply put, EA provides a clear and concise picture that defines your organization’s current and future information technology landscape, and helps set a framework for your organization to align to.
EA is also used as a communication tool between your business units (including the CxO level), and your IT department. It is your guiding principles, framework and agreement on how your business needs alignment with IT, and vice-versa, today and in the future.
Some of the most important IT components that EA drives include: Solution Architecture, Technology Architecture and Data Architecture. These components provide the technical guidance for your IT stakeholders to align to, and are based on the guiding principles and governance constituted by EA.
Solution Architecture (SA)
Solution Architecture is used to define your IT landscape at a more detailed level – specifically at a software/solution level. It is typically one layer below your EA, and is used to:
a. Document the structure and behavior of a technical solution to a business process/problem
b. Define a process for describing a technical solution and the tasks required to deliver that solution
Like EA, SA moves with your business processes. As your business needs change/evolve, your SA artifacts are updated to reflect your current technical state. Fundamentally, EA is used as your guiding principle in IT, while SA, including data/technical architecture (defined below), is used as a tool to define those principles at a granular level.
Technical Architecture (TA)
Technical Architecture often exists in several forms and names: Infrastructure Architecture, Hardware Architecture, System Design, etc.
TA is used to define your IT landscape at a hardware/network level. It is also one of the layers below EA, and is specifically used to:
a. Document and define your hardware configuration
b. Document and define your infrastructure applications that run on your hardware
c. Document and define your infrastructure services that are offered to those applications
d. Document and define your protocols, security and networks that connect these applications together.
TA is also used to address issues such as performance and resilience, storage and backup.
Data Architecture (DA)
Data Architecture is used to define your IT landscape at a data level. It is also one of the layers below EA, and specifically used to:
a. Document and define your approach for managing your data in your organization (e.g. master and transactional data)
b. Document and define your data governance models in your organization (e.g. who manages your master data and how)
c. Document and define your data relationships between various internal/external systems.
As with TA and SA, DA is guided by your EA principles and rules.
Architecture Frameworks/Methods
There are various ways to practice EA in your organization. Some vendors and software companies have created their own frameworks. Depending on your IT landscape, and business processes, one of these frameworks/methods may suit your needs. Selecting and adapting your organization to work with one, will help provide you with a template to build your EA practice and help scale/adjust it as your business grows and changes.
Below are a few examples:
> The Open Group Architecture Framework (TOGAF)
- This is a framework for enterprise architecture which provides a comprehensive approach to the design, planning, implementation, and governance of an enterprise information architecture.
> Zachman Framework
- This is a framework for enterprise architecture, which provides a formal and highly structured way of viewing and defining an enterprise.
> SAP Enterprise Architecture Framework (SAP EAF)
- This is a vendor specific architecture framework. It is a methodology and toolset that primarily supports the effective adoption of Service Oriented Architecture (SOA). It is based on TOGAF and specifically designed to support packaged solutions from SAP.
In summary, architecture is something an organization has to learn to adopt from the top down, and also to carefully manage and drive with an internal practice/team that can communicate and integrate IT stakeholders with business stakeholders. A well-defined architecture will improve your success rate in adopting/aligning IT solutions to solve your business problems and operate your business processes efficiently and cost effectively.
