IT Architecture Design Framework: ADMIT

ADMIT (Architecture Design (or Development) Methodology for Information Technology) is a decision-making tool for systematically developing a robust architecture using twenty design forces and strategies, as well as fifteen aspects of the lifecycle processes. This methodology defines an architecture development lifecycle, its phases and processes of managing the architecture development, and can be used in conjunction with other frameworks. Additionally, this paper discusses architectural levels and domains, resource dimensions, and how architecture relates to quality and design.

Introduction

In information technology, architecture plays a major role in the aspects of business modernization, IT transformation, software development, as well as other major initiatives within the enterprise. IT architecture is used to implement an efficient, flexible, and high quality technology solution for a business problem, and is classified into three different categories: enterprise architecture, solution architecture and system architecture. Each of these classifications varies in their implementation and design, depending on the contextual business scope, organization structure, and corporate culture.

Architecture Level

Architecture level represents the scope boundary and granularity of details the architectural activity should take, based on organization hierarchy and communication audience.

Enterprise Architecture (Company level) aligns technological strategies and execution plans with business visions and objectives by providing architectural oversight and guidance. Enterprise architecture also drives consolidation, reuse, and economy of scale by addressing company-wide goals in a holistic way across all IT projects.

Solution Architecture (Department level) models a solution vision that defines the IT systems, business processes and reusable services for a specific business unit, spanning across business and technology architectures.

System Architecture (Team level) defines the structure of an information system in terms of various subsystem components and their relationships with internal and external systems. System architecture focuses on application, data, and technology, and is called software architecture in some organizations.

Table 1 - IT Architecture Classification/Hierarchy

Architecture Domain

IT architecture encompasses four domains from an information management perspective, based on the components of enterprise, solution, and system architectures.

Figure 1 - IT Architecture Domains

Business Architecture (Why domain) represents the business-centric view of the enterprise from a functional perspective. Business processes, business services, and business rules are defined and designed along with the business operating model, business performance goals, and organizational structure. Architecture at any level, starts from this domain and cascades down to technology architecture.

Information/Data Architecture (What domain) describes the data assets and management resources, such as information catalogs, data models, data-flows, data quality, and data security, to support critical business functions and the governance models to share data across enterprise.

Application/Service Architecture (How domain) provides the blueprint for applications and services and their alignment with other business processes and services. Application architecture defines the logical and physical components, object models, process-flow, and cross-cutting concerns such as caching, validation, transaction etc.

Technology/Technical Architecture (Where domain) addresses the technology stack, data center, cloud delivery, network topology, and security architecture. The technology stack includes server, storage, virtualization, operating system, and middleware.

Architecture and Resource Dimension

Technology architecture prepares the infrastructure environment by optimizing the use of system resources to meet key business demands. In order to achieve better performance metrics, a balanced mix of workload, demand, throughput, and latency for a desired capacity and redundancy is required.

• Workload refers to the computational tasks being performed within the system. Workload consumes available processor capacity, which leaves fewer resources available for other tasks.
• Demand is the user load and addresses average and peak capacities for users at a particular point within the system. Demand mostly consumes memory for session, state and cache information.
• Throughput corresponds to the volume of data being transferred to and from a storage medium and is measured in terms of I/O operations per second or megabytes transmitted per second.
• Latency measures the round-trip time and the processing delay of network resources.
• Capacity is the raw resource power in a machine. Capacity is increased by augmenting CPU, memory, network connectivity, and storage capabilities in the server and contributes to scale-up architecture (vertical scaling).
• Redundancy refers to the case when multiple machines are sharing the workloads or system switches to other machine seamlessly when primary machine fails. This contributes to scale-out architecture (horizontal scaling).

How Architecture relates to Quality & Design

ADMIT defines the “architecture” of an information system as its structure and foundation in a run-time environment, embodied in its building blocks and characterized in their properties and relationships, in order to satisfy the functional requirements and achieve a desired set of quality attributes.

Modern IT architecture shares the same vitruvian triad that ancient Greeks defined for building architecture. Many experts define quality as the combination of fitness-for-purpose (feature) and fitness-for-use (attribute). Architecture enables and carries the qualities of system by exhibiting form, fitness and functionality.

System architecture focuses on both functional and non-functional requirements, and represents its high-level view, whereas system design deals with mostly functional requirements and represents low-level view with more implementation details. Architecture is driven by strategic initiative or business requirements, whereas design is based on architecture and follows architecture. They complement each other to implement a sustainable business solution.

Architecture Design Methodology for IT

ADMIT consists of 2 components:

• Architecture design forces (ADF)
• Architecture development lifecycle (ADLC)

Design forces focus on the strategies and techniques of developing the architecture systematically.

Lifecycle defines the phases and processes of managing the architecture development.

Architecture Design Forces (ADF)

In order to develop architecture with excellent system qualities, a structured thinking process is encouraged, so that the correct decision can be made to select the best possible option. ADFs are used to drive the methodical development of any architecture. They span across several areas of concern as shown in the following diagram.

(Click on the image to enlarge it)

Figure 2 - Architecture Design Forces

1. Business Force

A needs assessment from the business community should be considered first, in order to craft a successful solution. Business and IT will partner together to identify innovative solutions that satisfy requirements and adhere to IT strategy and standards. Architects transform ideas and concepts into systems and solutions; yielding the definition of business processes and services by applying their broad domain knowledge and business expertise.

2. Operation Force

Non-functional requirements, such as system health monitoring, administration, service level agreements, and operational concerns usually comes from the business and IT operations. Despite not originating from direct client needs, meeting these requirements and pursuing operational excellence is a vital component of any architectural work.

3. Aestheticism Force

Artistry and aestheticism should come into play because of human interaction with the systems we create. Architectural design delights people and raises their spirits. Seamless, effortless and attractive user interface will enhance customer experience and engagement. Helping business with right mix of technology, process, and pragmatism is a combination of both science and art. For that, left and right brains should be fused to think outside of box.

4. Future Force

In addition to current requirements, architects have to consider the relevance of the solution for next five to ten years, so that a sound and solid architecture can be built to cater the expected growth pattern. Think ahead by introducing abstraction layers (boxes on flow chart or interfaces in code), but defer implementation until it is required.

5. Simplicity Force

Simplicity not only improves the understandability of the system to its stakeholders, but also saves cost in the long run. However, sometimes complexity is unavoidable in the enterprise. Architects should be able to identify and manage the necessary complexity by abstraction or decomposition, and prevent the design entropy from taking hold. In the real world, complex systems evolve from simple working systems.

6. Change Force

In order to be competitive in the market place, we have to embrace and adopt changes quickly. For this reason, systems should be easily configurable using metadata and properties. Architecture will be better off if it is based on common foundation and building blocks to enable agility and flexibility.

7. Process Force

Outdated business processes and custom solutions should be reengineered to deliver both current and future requirements. Standardized and integrated business processes build core capabilities for execution and growth. Industry standard processes are appropriate for most functions, unless a clear competitive reason exists for a custom solution.

8. Integration Force

Integration plays a major role in sharing data between applications as well as external business in the case of corporate acquisitions. To maintain flexibility and interoperability, integration should be loosely-coupled and standard-based. Common integration patterns and messaging protocols prevent the proliferation of redundant technologies and reduce maintenance costs.

9. Implementation/Pattern Force

Architects need to provide implementation details like object models (UML), data models (ERD), shared components, data-flow diagrams, dependency graphs, service APIs, communication protocols, messaging structure, etc. to the delivery team. These patterns, frameworks, and standards play an important role in architecture design. Patterns are proven solutions of a problem within a given context. Frameworks are the implementation kits for architecture and design patterns. Technology standards are used to improve interoperability of the system.

10. Enterprise Force

Having enterprise systems, shared IT infrastructure, and company-wide core data store provides global synergy, promotes efficiency of processes, and saves overhead costs, compared to building business silos for each business vertical. Focus should be on system reusability, core business processes and master data management.

11. Constraint/Environment Force

In the organization, there may be some constraints that inevitably need to be addressed. These constraints can be related to personnel, technology, or time. We need to balance those constraints while designing the architecture. Architecture is also influenced by many environmental factors such as the organization’s structure and culture, as well as individual employee’s influence and corporate politics.

12. Failure Force

Protecting systems from a single point of failure is achieved by considering fault-tolerance, redundancy, and data replication in the architecture. Over time all hardware and software systems fail. We need to plan for success scenarios, as well as failure scenarios in order to mitigate this risk.

13. Channel Force

Companies target different customer segments via multiple channels, such as mobile, web, social media, and on premises kiosks to provide unique and differentiating user experiences. Architects need to consider various tangible devices that are available to reach the consumer, and their related technologies at the client tier for mass adaption.

14. Content Force

Content such as data and information is an enterprise asset that needs to be governed and delivered in an efficient way. Content sourcing, integration, and distribution are some of the important aspects of content strategy.

15. Platform Force

Platform covers the operating systems, virtual servers, middleware, database, and other technologies that deliver products. They play a major role in overall architecture in application and data space.

16. Infrastructure Force

To design a highly scalable and reliable infrastructure, architects consider server sizing and cluster environments to balance the workload for multiple servers and to protect the system from single point of failure. Infrastructure includes hardware stacks and the datacenter facility.

17. Network Force

To design a distributed system for a globalized environment, we have to consider next-generation networks including mobile and cloud and prepare deployment topologies with the proper network segmentation and firewall protected perimeter security.

18. Storage Force

Protecting data’s integrity is one of the most important elements in IT. These assets should be stored in a persistent storage medium such as NAS, SAN. Attention should be paid to define data replication strategy, backup and retention policy, restore and cleanup procedure.

19. Security Force

Companies formulate security policies to meet the legal and regulatory requirements of compliance, governance, and privacy in addition to protecting the organization and its brand from various risks. These policies are enforced as part of network security, application and data security, platform security, and physical security.

20. Cost Force

Minimizing cost and maximizing quality is everybody’s business in IT. Architects explore multiple of design options and their associated trade-offs in order to measure their cost and effectiveness before deciding the best possible solution of the business problem. Efficient technology is always good for company’s bottom-line.

Architecture Development Lifecycle (ADLC)

In order to manage architecture development effectively, fifteen processes have been defined in the lifecycle. These processes are agile and iterative, and are grouped into five phases: planning, design, management (from development area), optimization (optimization area) and automation (automation area) as shown below.

Figure 3 - Lifecycle Diagram

Table 2 - Processes, Phases & Areas in Architecture Development Lifecycle

1. Identify business vision and strategy

Business vision and strategic plan are identified in this process. Architecture is initiated by a business case and its objectives. This will form the basis of business architecture.

2. Plan stakeholder management (requirement management)

Stakeholders are identified for the architecture initiative. Managing their expectations, requirements, and communication needs are keys to success of any architecture implementation. Relationship management, communication, and negotiation play crucial parts in this process.

3. Define architecture and technology strategy

Management and strategic direction are defined by technology standards, asset governance, and portfolio management. Key technology decisions such as buy versus build or cloud versus premises are also considered as aspects of this strategy.

4. Assess current architecture

Architecture assessment is performed by reviewing the overall requirements of the new system and comparing them with the state of the current architecture using SWOT, MoSCoW, and other techniques. Based upon this assessment, a list of best practices is recommended for architecture advancement and adoption in later phase.

5. Design target architecture

In order to execute the proposed business strategy or to meet business requirements, the target architecture with future processes is developed using the aforementioned architecture design forces. Sometimes transition architectures are identified to deliver continuous business value before reaching the target architecture.

6. Conduct gap analysis

The current and target architectures are compared and gaps between them are identified. Impacts on upstream and downstream systems and existing processes are analyzed; identifying dependencies, synergies, risks, assumptions, and constraints that should be addressed during implementation.

7. Develop execution roadmap

Based on identified gaps, an execution roadmap with multiple project and program initiatives and sequencing action plan is developed to migrate from current state to future state, based on business priorities, costs, and expected value.

8. Build reference architecture (architecture pattern)

Reference architecture provides the architectural foundation and guidance via solution blueprints and models for future implementations across multiple organizations or business units. Architects need to implement standard, reusable platforms, and formulate best practices and repeatable patterns in their own technology’s “center of excellence”.

9. Review architecture with stakeholders

Architects need to socialize their solutions with stakeholders in order to garner support and establish consensus. Engineering solutions, architecture views, and roadmap are reviewed with stakeholders and validated for viability and feasibility in regularly scheduled checkpoint meetings to get their approval and buy-in.

10. Initiate a quick-win project

In order to realize the business value quickly, it is recommended to begin with a foundation project that emphasizes accelerating the implementation’s time-to-market. This project prepares the organization and IT environment for the future solutions that will be implemented.

11. Perform implementation governance

An architecture team will manage and monitor where the architecture standards and guidelines that are being followed by the delivery teams during regularly scheduled project architecture reviews.

12. Manage lifecycle changes

This process ensures that the architecture responds to the changing needs of business during its lifecycle. Architecture changes need to be evaluated and analyzed for their impact and then managed proactively in a controlled manner.

13. Manage architecture assets

Architecture assets are used to communicate the stakeholder’s concerns and referred to as a knowledge area for future architecture works. Deliverable artifacts such as views, models, catalogs and other assets need to be recorded and managed within a content repository in order to be congruent with version, approval, and access controls.

14. Improve architecture and process continuously

Continuous improvement of the product, process, and personnel is a key element in delivering quality solutions. Architectures are improved and optimized iteratively to maximize their value to the business. Similarly, lifecycle processes should be improved and streamlined over time in order to achieve efficiency.

15. Automate lifecycle with tool and technology

Architecture development is a process that has specific objectives and uses tools and techniques to convert inputs into output deliverables. Architecture development and the management of its processes depend heavily on architect’s skill and experience. Appropriate tools and technologies should be used to automate some parts of the development lifecycle in order to assist architects in a well-established architecture practice.

Conclusion

This generic methodology only describes high-level forces and process objectives without any implementation details. Organizations can tailor ADMIT by customizing its design forces and implementing its processes, based on their own needs, size of their organization, and scale of their solution.

ADMIT would be the way to apply the classic architectural themes of ancient Greeks to modern IT architecture for the implementation of winning solutions. May this open methodology be a helpful tool for architects and those who are braving the nebulous sea of technological changes and challenges every day.

Acknowledgement

I’d like to thank my managers – Leo Modica & Vlad Boroditsky at Nokia and former mentors at Walgreens & JPMorgan Chase for inspiring me to think critically and creatively. Also I’d like to acknowledge my past and present colleagues for bearing with me to discuss some technical and whimsical topics near water-cooler during time-out. A big thank to Harry Brumleve for his great review and feedback. Pride of place goes to my wife – Ambapali for her patience and support.

About the Author

Suman Pradhan, PMP is a senior business technologist with more than 18 years of IT experience in financial, banking, retail, healthcare, location (map) and technology industries. His research and interest includes IT architecture, application development & management, information security, and web, integration & distributed technologies. He is currently a senior IT architect at Nokia.