Solution Architecture

Welcome to your new world. Learn fast, learn deep, learn wide.

TOGAF

Enterprise architecture is an approach to describe the structure of an enterprise. Enterprise architecture can be described in three attributes,discipline, process and work produc.

Slides

Architecture Development Method

The ADM helps technologists manage the architecture of an enterprise. An enterprise may consist of many subsidiaries in many businesses. It is important that technologists are not disconnected from the business the enterprise is involved in. Alphabet for example, is the holding company of multiple companies including Google, Youtube, and Android.

Think about how you may apply the ADM when a large enterprise sets off on a major project to merge many legacy applications and databases.

Every stage of the ADM have similar themes: objectives, inputs, steps, approach, and outputs. Almost all stages produce some form of deliverables documentation which are stored in a repository.

Get ready to absorb everything.

Preliminary

The preliminary phase prepares the project before it is started.

Five activities take place:

1. Develop organisation model for enterprise architecture. This scopes out the impact of the project (hard, soft, extended) on various stakeholders. Relevant stakeholders are identified through the RACI model.
2. Develop architecture principles. The BDAT principles (business, data, application, technology) are used to set a universal tone across the enterprise.
3. Develop business principles, goals, and drivers. Whether it is to cost save, innovate, or spark a competitive advantage, there should be a business goal a project is attempting to achieve.
4. Develop architecture repository. Each phase of the ADM will produce some form of documentation of deliverables. The repository stores these documents for record keeping and tracking progress.
5. Develop request for architectural work. Sponsoring organisations request for work to architecture organisation through this document.

This phase sets the stage for the next phase, the Architectural Vision.

A. Architecture Vision

The architecture vision phase sets the expectation right between all stakeholders involved. Staked holders are identified through the interest vs power matrix. The key parties involved are the sponsoring organisation and architecture organisation. The vision assesses the organisation's current state and future state. Capabilities, gaps and drivers for the organisational change are analysed.

Five activities take place.

1. Develop architecture vision. Stakeholders affected by the architectural change are identified. The stakeholder interest vs power matrix is used to better manage them.
2. Develop a communication plan. Like in the preliminary phase, the RACI model is used to effectively communicate with the stakeholders.
3. Confirm business principles, goals and drivers.
4. Develop capability assessment. TOGAF defines capability as the ability of an organisation, system or process. Identifying capabilities allow an organisation to transform in the direction of its strength.
5. Develop statement of architecture work. In the previous phase, the request for architectural work was sent from the sponsoring organisation to the architectural organisation. In this phase, a statement of architectural work is sent back to the sponsoring organisation to be signed-off and agreed. It should contain the background of the transformation, scope of work, stakeholders' concerns, acceptance criteria, communications plan, project schedule and approvals.

At the end of this stage, an architectural vision should be produced to set the direction of the transformation. Notice that stakeholders from the sponsoring organisation are heavily involved in this stage.

B. Business Architecture
C. Information Systems Architecture
D. Technology Architecture

Phase B, C, and D will be discussed together because they perform the same activities for three separate domains - business, information systems, and technology. The goal of these phases are to produce a baseline and a target architecture for each of the three. The difference between the baseline and the target is called the gap. Diagrams can be used to visualise the baseline and target with colour-coded components to identify the components that are in the baseline, target, or both. There has to be a justification in the approch chosen to address the gaps. The deliverables of these phases are the architecture definition document and architecture requirements specification.

1. Develop architectural definition. This defines the business, information system and technology of an organisation. The business domain focuses on product, strategy and geography. Information systems focuses on data, applications, and the relationship between the two. Technology focuses on software components, infrastructure, and interphases between them.
2. Develop architecture requirements specification. It is the condition or capability and organisation must conform in creating an enterprise architecture. This is a set of statements that describe a change, the reason behind the change, and a KPI. Consider the following statement, "Server X is retired due to performance issues and replaced with cloud technology. Projections of $100000 cost savings are projected by the end of 2021."

E. Opportunities and Solutions

Up to now, all the phases involve only the architectural planning of an enterprise. None of them have been delivered yet. Phase E looks into the outputs from the past phases and plans its initial implementation. The output of this phase are work packages - a statement of the simplest for of work to be done. In TOGAF, they are a group of changes that will take place during the implementation of the architecture. In cases where there is a big gap between the baseline and target, one or more transition architectures maybe needed before arriving the target. Transition architectures are simply milestones of incremental changes before achieving the full transformation at the target. Some transition architectures can have more than on path operated by AND or OR to achieve the target.

1. Develop architecture roadmap. An implementation factor assessment is a document listing all possible factors of an architecture. Factors are issues that must be resolved before a change can be successful. Risk, assumptions, and dependencies are examples of factors.
2. Develop implementation and migration plan. Workflow and timeline diagrams are produced to track the progress of architecure implementation from beginning to end.

At the end of phase E, an architecture roadmap and implementation and migration plan should be produced. The architecture requirements specification should also be updated.

F. Migration Planning

The first half of the ADM (up to phase E) are very much enterprise architect driven. The second half beginning from phase F onward relies more heavily on change agent in the enterprise. Phase F finalises detailed the two documents produced in Phase E - the architecture roadmap and implentation and migration plan. Key stakeholders are educated on the ROI, cost of work packages, the transition architecture and the target architecture of the enterprise.

G. Implementation Governance

The role of enterprise architects in phase G is to provide oversight and ensure delivery of the planning that has been done from the preliminary phase to phase F. They do this by confirming the scope and priorities, guiding development and solutions deployment, and performing compliance reviews. The architecture contract is the key document to drive implementation.

H. Architecture Change Management

Requests and demands seldom remain constant throughout the lifecycle of a project. Factors that can put pressure on new demands are new technologies, changes in business environments and governance requests. This phase puts in place a procedures to manage new change requests while ensuring the architecture continues delivering its business value. New requests are assessed if some phases should be updated or if a new cycle of the ADM is required.

Requirement Management

Requirements should always be monitored at every phase to allow the ADM to adapt to the needs of the organisation.

Read General TOGAF

Read Architecture Development Method

Read Content Metamodel

21 principles of The Open Group Architecture Framework

Business principles

1. Primacy of Principles. These principles of information management apply to all organizations within the enterprise.
2. Maximize Benefit to the Enterprise. Information management decisions are made to provide maximum benefit to the enterprise as a whole.
3. Information Management is Everybody's Business. All organizations in the enterprise participate in information management decisions needed to accomplish business objectives.
4. Business Continuity. Enterprise operations are maintained in spite of system interruptions.
5. Common Use Applications. Development of applications used across the enterprise is preferred over the development of similar or duplicative applications which are only provided to a particular organization.
6. Service Orientation. The architecture is based on a design of services which mirror real-world business activities comprising the enterprise (or inter-enterprise) business processes.
7. Compliance with Law. Enterprise information management processes comply with all relevant laws, policies, and regulations.
8. IT Responsibility. The IT organization is responsible for owning and implementing IT processes and infrastructure that enable solutions to meet user-defined requirements for functionality, service levels, cost, and delivery timing.
9. Protection of Intellectual Property. The enterprise's Intellectual Property (IP) must be protected. This protection must be reflected in the IT architecture, implementation, and governance processes.

Data Principles

10. Data is an Asset. Data is an asset that has value to the enterprise and is managed accordingly.
11. Data is Shared. Users have access to the data necessary to perform their duties; therefore, data is shared across enterprise functions and organizations.
12. Data is Accessible. Data is accessible for users to perform their functions.
13. Data Trustee. Each data element has a trustee accountable for data quality.
14. Common Vocabulary and Data Definitions. Data is defined consistently throughout the enterprise, and the definitions are understandable and available to all users.
15. Data Security. Data is protected from unauthorized use and disclosure. In addition to the traditional aspects of national security classification, this includes, but is not limited to, protection of pre-decisional, sensitive, source selection-sensitive, and proprietary information.

Application Principles

16. Technology Independence. Applications are independent of specific technology choices and therefore can operate on a variety of technology platforms.
17. Ease-of-Use. Applications are easy to use. The underlying technology is transparent to users, so they can concentrate on tasks at hand.

Technology principles

18. Requirements-Based Change. Only in response to business needs are changes to applications and technology made.
19. Responsive Change Management. Changes to the enterprise information environment are implemented in a timely manner.
20. Control Technical Diversity. Technological diversity is controlled to minimize the non-trivial cost of maintaining expertise in and connectivity between multiple processing environments.
21. Interoperability Software and hardware should conform to defined standards that promote interoperability for data, applications, and technology.

Simplified TOGAF

Enterprise architecture principles

1. Applications - should be engineered for maximum efficiency.
2. Build vs buy - buying uncustomised and readily available solutions should be the first choice. Build only for competitive advantage.
3. Infrastructure - should be simplified.
4. Processes - should be automated with the least human intervention possible.

Application architecture principles

1. Design for simplicity.
2. Represent business rules in the best way possible across the bank.
3. Promote reusability of common services and interfaces.
4. New systems must co-exist with legacy systems.
5. Standardize messages and interfaces between operating systems.
6. Build a core and share the foundation.
7. Take an end-to-end data flow approach when designing new systems.

Data architecture principles

1. Data should have an ownership.
2. One source, use many.
3. Each reference should have a golden source.
4. A common definition for data should be used across the group.
5. All data transformations should be time-stamped, audit trailed, and backward-linked to its source.
6. Data should be repaired and validated from its originating system.
7. Data should flow downstream should be captured in near real-time.
8. Data security should be managed via role-based access.
9. Data-flows should be designed end-to-end following these principles.

Others

Types of network diagrams

1. Bus

   

2. Ring

   

3. Star

   

4. Mesh

   

5. Tree

   

Best practices

1. Avoid arrows crossing each other.
2. Use straight arrows.
3. Point arrows from left to right.
4. Be as minimalist as possible.
5. Diagrams should have only one start event and one end event.

3-tier architecture

The three tiers can be separated into distinct layers

1. Web presentation layer. Most understood as the front-end of an application. Written in HTML, CSS, and JS.
2. Application layer - contains the business logic of the application. Often written in Java, .NET, Python, C#, C++.
3. Back-end layer - contains the database and storage of the applicaiton. Written in MySQL, Oracle, MongoDB.