Architectural Governance
This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA
Overview
Download & View Architectural Governance as PDF for free.
More details
- Words: 6,601
- Pages: 24
Architectural Governance
Page 1
K NOWLEDGE M ANAGEMENT
A RCHITECTURAL G OVERNANCE G OVERNANCE , P LAN , M ETHODOLOGY , R EQUIREMENTS & D ESIGN Status: Pubic Release (site neutral) July 2008 Version 1.0
Prepared by: Architecture Team: Steven D. Wright
© 2008 Knowledge Management. All Rights Reserved.
PAGE 1
Architectural Governance
Page 2
Report Control Sheet 1.
Project
Digital Publishing Project
2.
Report Type
Strawman Proposal; if approved: IT Policy
3.
Version
Version 0.1
4. 5. 6. 7. 8. 9. 10. 11. 12.
Date of Publication Authors Approvers Additional Reviewers Draft Distribution Final Distribution Last Modified Internal Revision Document Location
April 12, 2004 Steve Wright
Digital Publishing Development Team Public 7/3/2008 11:22:00 PM 4 C:\Documents and Settings\Steve\My Documents\My Templates\Architectural Governance.docx
AMENDMENT HISTORY Version
Status
Date
Comments
0.1
Draft
4/12/04
Internal documents
0.5
Release
various
Adapted and released as guidance to several companies under contract.
1.0
Release
6/3/08
Blended two
© Copyright 2008 Steven D. Wright d.b.a. Knowledge Management. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of Steven Wright.
© 2008 Knowledge Management. All Rights Reserved.
PAGE 2
Architectural Governance
Page 3
Table of Contents REPORT CONTROL SHEET .................................................................................................................... 2 TABLE OF CONTENTS ............................................................................................................................. 3 EXECUTIVE OVERVIEW ......................................................................................................................... 4 WHAT IS ARCHITECTURE? ................................................................................................................... 5 THE ARCHITECTURE TEAM ................................................................................................................. 6 RESPONSIBILITIES OF THE ENTERPRISE ARCHITECTURE TEAM ................................................................... 6 ARCHITECTURAL ROLES ............................................................................................................................. 7 RESPONSIBILITIES OF EACH ARCHITECT ..................................................................................................... 8 Chief Architect ...................................................................................................................................... 8 Applications Architect ........................................................................................................................... 8 Data Architect ....................................................................................................................................... 8 Information Architect ............................................................................................................................ 9 Internet Architect .................................................................................................................................. 9 Network Architect ................................................................................................................................10 System Architect ...................................................................................................................................10 Security Architect .................................................................................................................................10 Process/Methodology Architect ...........................................................................................................11 Project Architects (PA) ........................................................................................................................11 ARCHITECTURAL STANCE ..................................................................................................................13 ARCHITECTURE DEVELOPMENT PROCESS .................................................................................................13 ARCHITECTURAL FOUNDATIONS ...............................................................................................................14 APPLICATION STACK .................................................................................................................................14 ARCHITECTURAL LAYERS .........................................................................................................................16 Ubiquitous Services .............................................................................................................................17 NON-FUNCTIONAL QUALITY REQUIREMENTS .............................................................................18 Business Qualities ................................................................................................................................18 User Qualities ......................................................................................................................................19 Administrator Qualities .......................................................................................................................19 Qualities of Service ..............................................................................................................................21 Software Life-Cycle Qualities ..............................................................................................................22
© 2008 Knowledge Management. All Rights Reserved.
PAGE 3
Architectural Governance
Page 4
Executive Overview The governance of enterprise architecture is based on an understanding of the strength and integrity intrinsic in the people and technologies used in the business while also understanding the weakness and opportunities for miscommunication that is extrinsic between these same people and technologies when applied to business goals. In each of the sections that follow we will answer: What is an Enterprise Architecture? What are the various roles of an Architecture Team? How is an Enterprise Architecture developed and communicated, including selection of technologies, standards and design patterns? What are the many competing “system qualities” that must be balanced preliminary to any determination of an architecture?
© 2008 Knowledge Management. All Rights Reserved.
PAGE 4
Architectural Governance
Page 5
What is Architecture? ANSI/IEEE Std 1471-2000, Recommended Practice for Architectural Description of Software-Intensive Systems, provides the following definition for architecture: Architecture is defined by the recommended practice as the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution. This definition is intended to encompass a variety of uses of the term architecture by recognizing their underlying common elements. Principal among these is the need to understand and control those elements of system design that capture the system’s utility, cost, and risk. In some cases, these elements are the physical components of the system and their relationships. In other cases, these elements are not physical, but instead, logical components. In still other cases, these elements are enduring principles or patterns that create enduring organizational structures. The definition is intended to encompass these distinct, but related uses, while encouraging more rigorous definition of what constitutes the fundamental organization of a system within particular domains. Here is my definition for Enterprise Architecture: Enterprise Architecture is the set of decisions that must be made at the enterprise level before specific applications are designed and built in order to provide conceptual integrity and sanity across the enterprise’s systems. Architecture includes a decomposition of the systems into separate orthogonal viewpoints along with the enforced rules that enable this clean decomposition and isolation of design viewpoints. This is done so functional (application requirements) and non-functional (system qualities) and other aspects of the application system may be defined and built by independent specialists in their specific field. An architecture not only divides the system, it also divides the roles and responsibilities of those who work with the system into separate organizational concerns and disciplines that are conceptually tractable and can be effectively managed. An architecture must also incorporate trade-offs aware that attempts to optimized every desired feature is not possible and can result in systems that do not function effectively.
© 2008 Knowledge Management. All Rights Reserved.
PAGE 5
Architectural Governance
Page 6
The Architecture Team Architects are divided into Enterprise Architects and Project Architects (PA). Enterprise Architects are focused at the IT enterprise level and connectivity between multiple applications. Enterprise Architects are geared to be more proactive, less reactive; more strategic, less tactical. Enterprise Architects provide guidance to the Project Architects who apply enterprise standards and guidelines at the project level. Project Architects are focused at the project level and working with the developing vendor to design and implement the project. PAs report to Project Managers, but have a dotted-line responsibility to the Enterprise Architects in order to maintain consistency and interoperability across systems.
Responsibilities of the Enterprise Architecture Team
Responsible for translating business requirements into systems qualities and thence into repeatable design strategies and patterns that enable those qualities (e.g. adaptability, scalability, availability, non-repudiation, reusability, etc.). Responsible for enterprise application integration (EAI). This includes defining the opportunities for integration, selecting the tools, specifying the shared data & code resources, defining the interfaces and data-flows, and monitoring the success of said integration. Compiles or designs architectural models of current and proposed systems across the enterprise for use internally and in conjunction with Technology Partners. The models are of two types: o Enterprise Models that depict the entire enterprise and its inter-relationships. o Reference Models that depict recommended & approved technologies & designs, which can serve as a template for future projects. These models cover the following viewpoints: o API Stack of blessed Open Standards and Proprietary Technologies (expanded OSI 7-Layer Model) o Application Map o Data Flow Diagram o Business Process Models (from the Business Process Group) o Logical & Physical Data Schema
© 2008 Knowledge Management. All Rights Reserved.
PAGE 6
Architectural Governance
Page 7
o
Hardware Infrastructure Diagram o Network LAN & VLAN Infrastructure Diagram o Also, where needed to clarify application requirements, Unified Modeling Language (UML) diagrams, viz.: Use Case, Class, Package, Object, Sequence, Collaboration, State-chart, Activity, Component and Deployment Diagrams. Establishes the Design Repository and Metadata Repository for integrating all aspects of these models, and provides oversight of its use in conjunction with integrated Tool sets. Perform design reviews across the organization. (Note: not code reviews.) Leads the evaluation of vendor software targeted for possible integration into the systems or environment, including strategic applications, tools, and utilities. Defines the IT design methodology, development process methodology and best practices. Surveys external emerging developments, and evangelizes new technologies, standards and methodologies that will have a positive impact on the company's bottom-line and quality of service. Participates in external standards body work that defines IT standards in the health community.
Architectural Roles The Architecture team is divided into a number of roles based on an orthogonal “separation of concerns”: Chief Architect Applications Architect Data Architect Information Architect Internet Architect Network Architect Systems Architect Security Architect Process Architect Project Architects (PA) All but the last role comprise the Enterprise Architects. Each role (with the exception of the PA) is focused on issues at the enterprise level and across all projects. Due to the shortage of resources many architects hold more than one of the positions described below. In some cases there
© 2008 Knowledge Management. All Rights Reserved.
PAGE 7
Architectural Governance
Page 8
already exists a central department within the company that has an enterprise focus on one of these roles. In this case the Enterprise Architect may reside in this team and be matrixed into the Architecture team. By this means all architectural work is coordinated across all dimensions and projects.
Responsibilities of Each Architect Chief Architect
Coordinates and facilitates the activity of the Enterprise Architects and Project Architects with existing projects; removing roadblocks where necessary. Takes proactive escalation of probable system problems or design flaws to upper management before serious impact on ROI. Assures the complementary synthesis of all standards, models, designs and methodologies recommended by the Enterprise Architects. Acts as evangelist of the work and recommendations of the architecture team.
Applications Architect
Selects the paradigm and technology for application program-toprogram communication (APPC) among the components. Determines the overall priority ranking of each of the possible system qualities (cost, reusability, robustness, etc.) so the other architects can design models that enforce the “balance of concerns”. Responsible for defining the application tiers, frameworks, components types and interfaces. Also, creates the first-draft graphical template of UML design models used by the Project Architects. Specifies and provides ownership of reusable application components or reusable application code.
Data Architect
Sets Data Policy and the technical solution for the management, storage, access, navigation, movement, and transformation of data. Specifies recommended DBMS and ETL tools and technologies for structured and unstructured content. Creates and maintains the Metadata Repository. Creates a semantically rich business model of the enterprise problem domain that: o Is independent of any technology solution o Defines the Content of the business
© 2008 Knowledge Management. All Rights Reserved.
PAGE 8
Architectural Governance
Page 9
Compiles and maintains the Enterprise Schema across all applications. Enforces principles of good canonical data design. Examines and enforces opportunities to provide data reuse, balancing the issues of centralization and replication. Ensures the preservation of strategic data assets as applications and technologies de jure come and go. Reviews the policies and work of the Data Base Administrators.
Information Architect Because there already exists a central Web Hosting team the Information Architect may reside in this team and be matrixed into the Architecture team. Richard Saul Wurman, the father of information architecture, describes the role in these words: “The individual who organizes the patterns inherent in data, making the complex clear.” “A person who creates the structure or map of information which allows others to find their personal paths to knowledge.” “The emerging 21st century professional occupation addressing the needs of the age focused upon clarity, human understanding, and the science of the organization of information” Defines the visual roadmap seen by the customers of the company with emphasis on making it easy for customers to find the needed data to make appropriate decisions regarding their medical care and management. Establishes branding policy and holds the UI templates. Establishes the personalization policy with a goal to building customer loyalty and relationship enrichment. Defines the recommended dialog flow for long-running transactions and “speech acts” in coordination with the Business Process Group.
Internet Architect
Monitors the emerging standards for B2B & B2C internet interaction and sets the standards and technologies to be used by the enterprise. These include the existing HTML, applet & XML standards, and the emerging web services and semantic net standards. Coordinates with the other architects on issues dealing with the quality flaws of the existing standards, especially security, session state and long-running transactions. Builds a composite reference model to be used on internet-based applications, incorporating the models provided by the system architect, network architect, security architect, and applications architect.
© 2008 Knowledge Management. All Rights Reserved.
PAGE 9
Architectural Governance
Page 10
Network Architect Because there already exists a central Network team the Network Architect may reside in this team and be matrixed into the Architecture team. Focuses on the lower-level transport protocols and the standards and technologies for enabling systems qualities via network command-and-control structures. Evaluates and selects the enterprise’s networking hardware. Manages the network topology. Establishes network operation center (NOC) command-and-control structures for auto-discovery, event monitoring, trouble ticketing. Facilitates the upgrade to the Web-Based Enterprise Management (WBEM) standard of the Distributed Management Task Force (DMTF) and select the appropriate Common Information Model Object Manager (CIMOM) for tracking the state of the enterprises assets.
System Architect
Focuses on the standards and technologies for enabling systems performance qualities, such as availability, scalability, recoverability, etc. Evaluates and selects the enterprise’s server hardware, operating system, job control. Supports the Applications architect in selecting the application framework. Balances the quality issues cost vs. robustness, and hardware architecture, such as share-nothing n-tier vs. share-all symmetric multi-processing (SMP). Monitors performance benchmarks provided by the Transaction Processing Council (TPC). In conjunction with the Project Architect (PA) sizes the application and selects the hardware and configuration to use. Participates in the drafting of Service Level Agreements (SLA). Establishes a process to monitor existing systems for performance problems and drafts system migration plan if necessary.
Security Architect
Monitors security guidelines, such as HIPAA. Establishes and enforces the Security Policy and Trust Model for Administrators to follow in delegating and granting application privileges. Establishes and enforces the Security Model, technologies and standards for system architects and designers.
© 2008 Knowledge Management. All Rights Reserved.
PAGE 10
Architectural Governance
Page 11
Tracks warnings of new types of security threats and assures that the systems in place guard against these threats. Establishes the systems for discovering, tracking and convicting abusers of security and system integrity. Performs periodic security audits on existing systems.
Process/Methodology Architect While the other architects are focused on what the system should contain, the process architect is focused on how the application should be designed and built. Reviews and selects the Design Methodology and Modeling Language. Methodologies may be based on the Zachman, Rational Unified Process (RUP), Catalysis, RM-ODP, Iconix, SAADAM, etc. The modeling language should incorporate the Business Process Model (BPML) and the Unified Modeling Language (UML). Reviews and selects the Process Management Methodology. It is recommended that the new iterative methodologies from the Agile Alliance be reviewed for adoption, esp. Feature-Drive Development (FDD). Defines roles & responsibilities and creates a template Project Plan for modification by Project Managers. Selects CASE & IDE tool & Design Repository. Communicates the above to the development teams, and is enforced by the Project Architects (PA). Manages the education of the PAs.
Project Architects (PA)
Responsible for translating application requirements and business process models (BPM) into component and interface specifications. Ensures that the Technology Partners and development teams adhere to the principles established by the Enterprise Architects. Designs first-draft graphical UML & ER models that are delivered to the software development & DBA teams.
© 2008 Knowledge Management. All Rights Reserved.
PAGE 11
Architectural Governance
Page 12
The activities of the Project Architect (PA) can be contrasted with the Project Manager (PM) as shown in the following table: Topic Software Development
Project Manager Organize project; manage resources, budgets, schedules
Requirements
Negotiate with marketing; emphasis on business process and user interface Handle hiring; performance appraisals, salary; motivate employees Introduce new technologies per architect’s recommendations Ensure quality of product
Personnel issues Technology Quality Metrics
Measure productivity, size, quality
Project Architect Organizes team or technology partner around design; manages dependencies Review requirements; emphasis on functionality and system qualities Interview candidates; provide input on technical capabilities of staff; motivate development team Recommend technology, standards, training, tools Ensure quality of design and operational control characteristics Ensure design goals are met, volumetrics do not exceed scale
© 2008 Knowledge Management. All Rights Reserved.
PAGE 12
Architectural Governance
Page 13
Architectural Stance Architecture Development Process The most fundamental decision that must be made is a ranking of the nonfunctional “qualities” that the systems must support (e.g. availability, security, non-repudiation, etc.). From this follows a determination of open standards and design patterns (frameworks) that will be incorporated into future applications. Next the vendors and products are selected that support the open standards. The set of products must integrate well with each other and align their API Stack to support the design pattern of the selected Application Stack (e.g. n-tier with clearly defined nodes). The tools used by the developers are selected to code, test and debug the application, and then the tools used to design the application is selected with the goal of using clear models to generate clean code for rapid application development (RAD) and model-driven architecture (MDA). The modeling process must conform with the selected development methodology for designing robust code that conforms to the business requirements. Requirements, models, code and test data is kept in a version-controlled Reuse Library that supports traceability and impact analysis showing precise time & budget slippage of a change in requirements. When complete, the above process may iterate to take advantage of low-hanging fruit where it is found that a product has a particularly good synergy with other products. These factors that influence application and development architecture can be show as: Management Methodology
Design Methodology
Design Tools
Development Tools
Architectural Qualities
Standards & Patterns
Application Stack
Requirements, Design, Code, QA Repository
© 2008 Knowledge Management. All Rights Reserved.
PAGE 13
Architectural Governance
Page 14
Architectural Foundations Previous architectural decisions at the enterprise level come into play when designing the architecture for new applications. Application Stack that depict recommended & approved technologies, frameworks and products in support of corporate standards. Reference Models that depict recommended & approved design patterns. Enterprise Models that depict the entire enterprise used to design interfaces between existing applications and the new application.
Target Architectures Architecture Development Method Application Stack (standards)
Reference
Enterprise
Model
Model
Business Requirements & Service Qualities
Application Stack The Application Stack can be represented as a matrix that shows the design tiers (layers) for the application, the open standards API Stack selected, the API stack of vendors and products blessed by the company (for volume purchase and training), the design and development tools used to model the design and generate/edit the source code and debug the application, and administrate and manage the application in the operational environment.
© 2008 Knowledge Management. All Rights Reserved.
PAGE 14
Architectural Governance
Page 15
Here is a partial example of an Application Stack. (This is not a recommendation of these technologies.) Layer
Open Standard
Communi- TCP/IP, HTTP, cation HTML, SSL Application Java, J2EE Data Access Storage Operating System Security
XML, XML Schema Relational, SQL, XML Unix LDAP
Technology Stack Apache
Dev. Tool
Operations Management Smarts, Remedy
WebLogic, JSP, WDK EJB, Documentum Oracle
Eclipse
Smarts, JMX, Remedy
ERwin
BMC
Solaris
Tckl
Smarts
SQLJ
NDS, Netegrity
For multi-tier systems the applications layers are spread over multiple hardware systems, each with their own stack, with the application connected across systems by communication protocol stacks offering a wide array of features in support of the robustness of the application. This can be graphically represented as API stacks that abstract the hardware horizontally and the application over hardware nodes vertically. Here is an example of a 3-tiered application represented across the top of the stack and the hardware interfaces across the bottom of the stack. The invocation and abstraction of the hardware goes down the stack, while the transparent communication protocol is shown touching the relevant components:
© 2008 Knowledge Management. All Rights Reserved.
PAGE 15
Architectural Governance
Page 16
Architectural Layers Application Architecture is an abstract system specification consisting primarily of functional components described in terms of their behaviors and interfaces and component-component interconnections. Each layer in the stack serves as an abstraction to the layer above it. Each layer on the stack must have a set of well defined interfaces that are on the same level of abstraction (that serves some specific purpose). Each layer is responsible for its own sanity check, and typically trusts each of the other layers to do the same unless the data is coming from an external source. Not every layer is used in every transaction. For example, a simple HTML interaction only goes down through the top several layers and then returns. Batch loading from a legacy system may skip several layers. However, if everyone develops their application along a layered architecture then they only have to worry about communication between the layers immediately above and below them. If their layer is sometimes skipped then they must provide a transparent module so the design rule that layers only interact with the layers immediately above and below them remains in effect with few exceptions. Specifying a sequence for top to bottom control flow prevents the problem of cyclic deadlock among objects. Implementation via purchased software packages (even crossing multiple layers) is permitted as long as “wrappers” are coded that can integrate the packaged within the overall architecture and as long as essential administrative control features are present for each layer (e.g. scalable configuration). Breaking the application architecture into a many layered onion facilitates the adaptability of an application while adding to its complexity. Here is an example that calls out most of the possible layers, starting from the customer interface down to the persistent storage:
Customer
Presentation
Transaction
Customer Applications & Applets
Browser, Java applet, Legacy system
Communications
HTTP, ftp, telnet, 3270, EDI, VPN, fax
Access
Security, Certification, Firewall, Encryption, Session Closure, Connection Context
Native Presentation
Layout XML to: HTML, Character, Record layout, EDI (via Templates+Rules), Validation
Generic Presentation
Semantic XML to Layout XML
Workflow Processing
Commerce Events, State Table, Workflow, Job Initiation, Temporal & Priority Control
Application Context
© 2008 Knowledge Management. All Rights Reserved.
PAGE 16
Architectural Governance
Data
Page 17
Application Logic
Custom application-specific code goes here
Business Object
Metadata markup, DB Data
Semantic Navigation
Ontology, Context, KQML, Semantic Undo
Enterprise Schema
Data Dictionary, Referential Integrity
Data Distribution
Heterogeneous navigation, Scale Redirection, Legacy Redirection
DB Transaction
Stored Procedures, ACID
Data View
SQL, Dataset
Physical Data Stores
Index/Cluster Architecture, Bloom Filter, Encryption, RAID
Semantic XML,
Ubiquitous Services Transparently supporting each layer of the communicating objects in the above diagram are the following facilities:
System Framework
Reusability, Interoperability, Accountability, Initiallization
(Communicating Objects)
The above layers go here
XML Dataware
Business Object Access
Middleware Management
Scalability, Messaging, Load Balancing, Monitor, Fail-over, Restart
Directory / Security
DNS, LDAP, X.500
Operating System, Network Protocol
System Administration
Hardware, Wire, Disks
© 2008 Knowledge Management. All Rights Reserved.
PAGE 17
Architectural Governance
Page 18
Non-Functional Quality Requirements The complexity of an application’s functional requirements is not the only driver of system cost. Often cost and complexity is driven by system features that are behind-the-scenes and distributed across all functions of an application, such as “high availability”. These non-functional requirements have a major impact on the architecture of a system. As it is not possible to satisfy all requirements simultaneously trade-offs must be made. Consideration of the selection and weight of each of these qualities is provided in the following table. The non-functional quality requirements for the system is ranked below with a “0” representing a quality that no effort is to be spent on—to—a “10” representing a quality that must be included even if it means additional cost and significantly delaying the release of the system. A “1” represents an optional, nice-to-have, feature. There should be only a few qualities set at “9” or “10”.
Quality
Rank
Business Qualities Affordability: The ability to build the system with minimum development cost in labor and tools.
5
Time-to-Market: The ability to build the system in the minimum amount of time and ahead of competition for the similar functionality.
5
Functionality: The ability of the system to perform all the business tasks it was created to do per the user’s requirements.
7
Regulatory Compliance: Adheres to governmental regulations. Buildability: Whether or not the architecture can reasonably be built using the budget, staff, and time available for delivery of the project. Buildability is an often-overlooked quality attribute. Sometimes, the best architects are simply too ambitious for a project team to complete given project constraints and environment. The design that casts a solution in terms of well-understood concepts is more buildable than a design that introduces new concepts.
© 2008 Knowledge Management. All Rights Reserved.
10
3
PAGE 18
Architectural Governance
Page 19
User Qualities Usability: How easy it is for the user to understand and operate the system. Usability can be broken down into the following areas: Learnability: How quick and easy is it for a user to learn to use the system's interface? Efficiency: Does the system respond with appropriate speed to a user's requests? Memorability: Can the user remember how to do system operations between uses of the system? Error avoidance: Does the system anticipate and prevent common user errors? Error handling: Does the system help the user recover from errors? Satisfaction: Does the system make the user's job easy?
2
Gratification: The ability to anticipate the needs of the user and give more than is asked. Most systems give only what the user specifies and requires the user to expend significant effort in stating the request. A system with gratification learns the user’s habits and preferences, and intervenes with quick solutions or alternatives when the user does not appear to making progress.
2
Localization: The ability easily adapt to multiple languages and locales.
2
Personalization: The ability of a user to adapt the look and feel of the system to their own taste.
3
Customer Compliance: Adheres to the interfaces, data structures and conventions of the customer’s systems without requiring modifications of their systems.
8
Accuracy: Ability to provide the right or agreed results or effects with the needed degree of precision. Includes the ability to resist or correct poor data quality.
8
Mobility: Ability to support mobile devices and cellular communications.
0
Administrator Qualities Manageability: Can be expressed in terms of how easy it is to monitor a system and detect operational characteristics related to performance and failures, how easy it is to configure systems, the processes used for effecting this control, and the degree to which the system can be managed remotely.
3
Administrability: Can be expressed in terms of how easy it is to configure an application and detect application characteristics related to functional usage, how easy it is to configure the application, the processes used for effecting this control, and the degree to which the application can be administered by multiple parties in cooperating roles.
7
Data Location Transparency: The business logic layer of the application does not know the physical location of the data. The data may be distributed to multiple locations at sites determined by the DBAs and administrators for tuning, fail-over, and storage resource control.
8
© 2008 Knowledge Management. All Rights Reserved.
PAGE 19
Architectural Governance
Page 20
Component Location Transparency: A client does not know where a target server object resides. It could reside in a different process on another machine across the network, on the same machine but in a different process, or within the same process. Different components can be distributed over multiple machines, or, copies of the same component can be distributed over multiple machines.
7
Implementation Transparency: A client neither knows how a target object is implemented, what programming or scripting language it was written in, nor the operating system and hardware it executes on. This is also a security issue.
2
Hardware Virtualization: The application may be moved unchanged as compiled from the testing to the operational environment and across multiple hardware environments. VMware is an example of such an approach.
1
Object (Server) State Transparency: When a client makes a request on a target server object, it does not need to know whether that object is currently activated (i.e. in the executing state) and ready to accept requests or not. The ORB transparently starts the object if necessary before delivering the request to it. This feature greatly helps recovery handling for distributed objects.
3
Communication Mechanism Transparency: A client does not know what communication mechanism (e.g., TCP/IP, shared memory, local method call, etc.) the ORB uses to deliver the request to the object and return the response to the client. Multiple communication strategies may be statically or dynamically set.
2
Security: The ability of the system to resist unauthorized attempts to access the system and denial-of-service attacks while still providing services to authorized users. Includes levels of authentication supported, granularity of authorization controls, and techniques utilized to ensure the integrity of resources.
9
Auditability: The ability to ensure that the previous system states can later be reconstructed and observed. Includes recording and analyzing activities to detect intrusions or abuses.
9
Accountability: The ability to ensure that the ultimate causes of the previous system states can later be identified. The ability to know who did what.
8
Confidentiality: keeping information secret only to those who are authorized to see it.
9
Anonymity: concealing the identity of an entity involved in a process.
3
Privacy: Ability to follow business rules in regard to the rights and responsibilities that govern the acquisition, disclosure, and use of personal information.
9
Data Integrity: ensuring information has not been altered by unauthorized means.
9
Data Authentication: corroborating the source of data
7
Access Control: restricting access to resources to authorized entities.
8
Non-Repudiation: The ability to provide legally accepted proof that a user executed a particular transaction, even if they deny having done it. Must be able to discriminate against spoofing and man-in-the-middle attacks.
5
© 2008 Knowledge Management. All Rights Reserved.
PAGE 20
Architectural Governance
Page 21
Qualities of Service Quality of Service (QoS): The ability to measure and stay within the guaranteed performance and availability limits for contracted services per SLA.
4
Scalability: The ability for the system to grow linearly by adding hardware as the number of users and transactions increase beyond initial implementation. For high scalability you typically need: Asynchronicity Statelessness Parallelism Pipelining Location Transparency Load Balancing GUIDs
5
Performance: A specification of the workload and the latency or throughput requirement. The form of the specification will depend on the type of system. In an interactive system, the form of the specification might be an abstract specification of the number of users and a deadline for response; in an embedded real-time system, the form of the specification might be a characterization of the input events and an associated deadline.
6
Responsiveness: A measurement of the system response time for a functional requirement.
6
Availability: The amount of time that the system is up and running. It is measured by the length of time between failures, as well as by how quickly the system is able to restart operations after a failure. For example, if the system was down for one day out of the last twenty, the availability of the system for the twenty days is 19/19+1 or 95 percent availability. This quality attribute is closely related to reliability. The more reliable a system is, the more available the system will be. The rule of thumb is that each additional “9” of availability raises system cost ten-fold.
7 99.9%
Survivability: The ability to reestablish operations after a catastrophic event that leaves all existing systems unusable.
8
Reliability: The ability of the system to operate over time. Reliability is measured by the mean-time-to-failure of the system.
8
Recoverability: The ability to resume operations after a hardware or software fault that halts the current systems. Is expressed by: 1. Capability to reestablish the level of performance. 2. Capability to recover the data. 3. Time and effort needed for it. Measured by Mean-Time-To-Repair.
7
Nomadicity: Having components (or mobile agents) that can survive relocation of the component and/or automatically discover alternative living peer components in the event that the peer components it was communicating with fail, or can continue to work without interruption should related components fail. The DNS internet, Microsoft Outlook/Exchange, and cellular phone system are examples of nomadic systems. Service Oriented Architecture (SOA) using UDDI can easily be made nomadic.
1
© 2008 Knowledge Management. All Rights Reserved.
PAGE 21
Architectural Governance
Page 22
Autonomic Computing: Autonomic computing derives its name from the autonomic nervous system and denotes its ability to free our conscious brains from the burden of dealing with the vital, but lower-level, functions of the body. As used in the software industry, autonomic computing refers to self-managing systems that are comprised of four core characteristics: self-configuration, self-healing, self-optimizing, and self-protecting. Transactionality: The ability to commit a unit of work or, in the case of an error, rollback the data across all tables and stores. To be transactional all of the ACID constraints (qualities) must be met: Atomic: all or nothing Consistent: logically correct transformation Isolated: no concurrency bugs Durable: survives failures
8
Software Life-Cycle Qualities Evolvability: The ability of a system to change over time with minimum phased cutover impact.
3
Composability: The ability to sell the system as separate components that can work on their own or together in harmony.
5
Extensibility: The ability to easily add new data and behaviors to existing code by the developers.
7
Tailorability: The ability easily adapt the system to the needs of a specific customer. Includes the ability to re-brand the user interface. Minimizes the effort needed to maintain separate code bases.
6
Adaptability: The ability to define business processes, business rules and refine data types by an application administrator dynamically, without needing code revision.
9
Maintainability: The measurement of how easy it is to change the' system to incorporate new requirements. The two aspects of' modifiability are cost and time. If a system uses an obscure technology that requires high-priced consultants, even though it may be quick to change, its maintainability can still be low.
3
Portability: Measures the ease with which the system can be moved to different platforms. The platform may consist of hardware, operating system, application server software, or database server software.
7
Reusability: The ability to reuse portions of the system in other applications. Reusability comes in many forms. The run-time platform, source code, libraries, components, operations, and processes are all candidates for reuse in other applications.
2
© 2008 Knowledge Management. All Rights Reserved.
PAGE 22
Architectural Governance
Page 23
Integrability: The ability to make the separately developed components of the system work correctly together as a whole. This in turn depends on the external complexity of the components, their interaction mechanisms and protocols, and the degree to which responsibilities have been cleanly partitioned, all architecture-level issues. Integrability also depends upon how well and completely the interfaces to the components have been specified. Integrating a component depends not only on the interaction mechanisms used (e.g., procedure call versus process spawning) but also on the functionality assigned to the component to be integrated and how that functionality is related to the functionality of this new component's environment.
6
Interoperability: Integrability measures the ability of parts of a system to work together; interoperability measures the ability of a group of parts (constituting a system) to work with another external system. The integrability of a system depends on the extent to which the system uses open integration standards and how well the API is designed such that other systems can use the components of the system being built
7
Testability: The ease with which software can be made to demonstrate its faults through testing (probability that the software will fail on its next test, given that it has at least one fault). How easily the system can be tested using human effort, automated testing tools, inspections, and other means of testing system quality. Good testability is related to the modularity of the system. If the system is composed of components with well-defined interfaces, its testability should be good.
3
Variability: How well the architecture can handle new requirements. Variability comes in several forms. New requirements may be planned or unplanned. At development time, the system source code might be easy to extend to perform new functions. At run-time, the system might allow pluggable components that modify system behavior on the fly. This quality attribute is closely related to modifiability.
3
Subsetability: The ability of the system to support a subset of the features required by the system. For incremental development, it is important that a system can execute some functionality to demonstrate small iterations during product development. It is the property of the system that allows it to build and execute a small set of features and to add features over time until the entire system is built. This is an important property if the time or resources on the project are cut. If the subsetability of the architecture is high, a subset of features may still make it into production.
7
Conceptual Integrity: The ability of the architecture to communicate a clear, concise vision for the system, also know as Architectural Style. Fred Brooks writes, “I am more convinced than ever. Conceptual integrity is central to product quality. Having a system architect is the most important single step toward conceptual integrity…. After teaching a software engineering laboratory more than 20 times, I came to insist that student teams as small as four people choose a manager and a separate architect” (Brooks 1995). Kent Beck believes that metaphors are the most important part of the eXtreme Programming methodology (Beck 1999). The metaphor is a powerful means of providing one or more central concepts for a system. The metaphor provides a common vision and a shared vocabulary for all system stakeholders. The metaphor provides a means to enforce conceptual integrity. When the design of the system goes outside the bounds of the metaphor, the metaphor must change or new metaphors must be added; otherwise, the design is going in the wrong direction. If any of these design decisions are made without the concept feeling right, the conceptual integrity of the system will be lost. Sometimes the system metaphor is an architectural pattern, such as MVC or Blackboard. These architectural patterns provide a common metaphor for system developers or others who understand the patterns.
5
© 2008 Knowledge Management. All Rights Reserved.
PAGE 23
Architectural Governance
Page 24
Non-obsolescence: If the system is intended to have a long lifetime, modifiability and portability across different platforms become important, as well as rejection of technologies that may become obsolete and vendors that may go out of business. Building in the additional infrastructure (such as a portability layer) to support modifiability and portability will usually compromise time to market. On the other hand, a modifiable, extensible product is more likely to survive longer in the marketplace, extending its lifetime.
6
Installability: The capability of the software product to be installed in a specified environment.
7
Co-existence: The capability of the software product to co-exist with other independent software in a common environment, sharing common resources.
1
Replaceability: The capability of the software product to be used in place of another specified software product for the same purpose in the same environment.
2
Standards Compliance: Adheres to external open standards.
7
The following qualities are absent from this list and may be added later if needed: flexibility, understandability, deployability, configurability, degradability, accessibility, demonstrability, footprint, simplicity, stability, timeliness, schedulability, openness, seamlessness, safety, trust, Error, Multi-Undo, feedback, empowerment
© 2008 Knowledge Management. All Rights Reserved.
PAGE 24
Page 1
K NOWLEDGE M ANAGEMENT
A RCHITECTURAL G OVERNANCE G OVERNANCE , P LAN , M ETHODOLOGY , R EQUIREMENTS & D ESIGN Status: Pubic Release (site neutral) July 2008 Version 1.0
Prepared by: Architecture Team: Steven D. Wright
© 2008 Knowledge Management. All Rights Reserved.
PAGE 1
Architectural Governance
Page 2
Report Control Sheet 1.
Project
Digital Publishing Project
2.
Report Type
Strawman Proposal; if approved: IT Policy
3.
Version
Version 0.1
4. 5. 6. 7. 8. 9. 10. 11. 12.
Date of Publication Authors Approvers Additional Reviewers Draft Distribution Final Distribution Last Modified Internal Revision Document Location
April 12, 2004 Steve Wright
Digital Publishing Development Team Public 7/3/2008 11:22:00 PM 4 C:\Documents and Settings\Steve\My Documents\My Templates\Architectural Governance.docx
AMENDMENT HISTORY Version
Status
Date
Comments
0.1
Draft
4/12/04
Internal documents
0.5
Release
various
Adapted and released as guidance to several companies under contract.
1.0
Release
6/3/08
Blended two
© Copyright 2008 Steven D. Wright d.b.a. Knowledge Management. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of Steven Wright.
© 2008 Knowledge Management. All Rights Reserved.
PAGE 2
Architectural Governance
Page 3
Table of Contents REPORT CONTROL SHEET .................................................................................................................... 2 TABLE OF CONTENTS ............................................................................................................................. 3 EXECUTIVE OVERVIEW ......................................................................................................................... 4 WHAT IS ARCHITECTURE? ................................................................................................................... 5 THE ARCHITECTURE TEAM ................................................................................................................. 6 RESPONSIBILITIES OF THE ENTERPRISE ARCHITECTURE TEAM ................................................................... 6 ARCHITECTURAL ROLES ............................................................................................................................. 7 RESPONSIBILITIES OF EACH ARCHITECT ..................................................................................................... 8 Chief Architect ...................................................................................................................................... 8 Applications Architect ........................................................................................................................... 8 Data Architect ....................................................................................................................................... 8 Information Architect ............................................................................................................................ 9 Internet Architect .................................................................................................................................. 9 Network Architect ................................................................................................................................10 System Architect ...................................................................................................................................10 Security Architect .................................................................................................................................10 Process/Methodology Architect ...........................................................................................................11 Project Architects (PA) ........................................................................................................................11 ARCHITECTURAL STANCE ..................................................................................................................13 ARCHITECTURE DEVELOPMENT PROCESS .................................................................................................13 ARCHITECTURAL FOUNDATIONS ...............................................................................................................14 APPLICATION STACK .................................................................................................................................14 ARCHITECTURAL LAYERS .........................................................................................................................16 Ubiquitous Services .............................................................................................................................17 NON-FUNCTIONAL QUALITY REQUIREMENTS .............................................................................18 Business Qualities ................................................................................................................................18 User Qualities ......................................................................................................................................19 Administrator Qualities .......................................................................................................................19 Qualities of Service ..............................................................................................................................21 Software Life-Cycle Qualities ..............................................................................................................22
© 2008 Knowledge Management. All Rights Reserved.
PAGE 3
Architectural Governance
Page 4
Executive Overview The governance of enterprise architecture is based on an understanding of the strength and integrity intrinsic in the people and technologies used in the business while also understanding the weakness and opportunities for miscommunication that is extrinsic between these same people and technologies when applied to business goals. In each of the sections that follow we will answer: What is an Enterprise Architecture? What are the various roles of an Architecture Team? How is an Enterprise Architecture developed and communicated, including selection of technologies, standards and design patterns? What are the many competing “system qualities” that must be balanced preliminary to any determination of an architecture?
© 2008 Knowledge Management. All Rights Reserved.
PAGE 4
Architectural Governance
Page 5
What is Architecture? ANSI/IEEE Std 1471-2000, Recommended Practice for Architectural Description of Software-Intensive Systems, provides the following definition for architecture: Architecture is defined by the recommended practice as the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution. This definition is intended to encompass a variety of uses of the term architecture by recognizing their underlying common elements. Principal among these is the need to understand and control those elements of system design that capture the system’s utility, cost, and risk. In some cases, these elements are the physical components of the system and their relationships. In other cases, these elements are not physical, but instead, logical components. In still other cases, these elements are enduring principles or patterns that create enduring organizational structures. The definition is intended to encompass these distinct, but related uses, while encouraging more rigorous definition of what constitutes the fundamental organization of a system within particular domains. Here is my definition for Enterprise Architecture: Enterprise Architecture is the set of decisions that must be made at the enterprise level before specific applications are designed and built in order to provide conceptual integrity and sanity across the enterprise’s systems. Architecture includes a decomposition of the systems into separate orthogonal viewpoints along with the enforced rules that enable this clean decomposition and isolation of design viewpoints. This is done so functional (application requirements) and non-functional (system qualities) and other aspects of the application system may be defined and built by independent specialists in their specific field. An architecture not only divides the system, it also divides the roles and responsibilities of those who work with the system into separate organizational concerns and disciplines that are conceptually tractable and can be effectively managed. An architecture must also incorporate trade-offs aware that attempts to optimized every desired feature is not possible and can result in systems that do not function effectively.
© 2008 Knowledge Management. All Rights Reserved.
PAGE 5
Architectural Governance
Page 6
The Architecture Team Architects are divided into Enterprise Architects and Project Architects (PA). Enterprise Architects are focused at the IT enterprise level and connectivity between multiple applications. Enterprise Architects are geared to be more proactive, less reactive; more strategic, less tactical. Enterprise Architects provide guidance to the Project Architects who apply enterprise standards and guidelines at the project level. Project Architects are focused at the project level and working with the developing vendor to design and implement the project. PAs report to Project Managers, but have a dotted-line responsibility to the Enterprise Architects in order to maintain consistency and interoperability across systems.
Responsibilities of the Enterprise Architecture Team
Responsible for translating business requirements into systems qualities and thence into repeatable design strategies and patterns that enable those qualities (e.g. adaptability, scalability, availability, non-repudiation, reusability, etc.). Responsible for enterprise application integration (EAI). This includes defining the opportunities for integration, selecting the tools, specifying the shared data & code resources, defining the interfaces and data-flows, and monitoring the success of said integration. Compiles or designs architectural models of current and proposed systems across the enterprise for use internally and in conjunction with Technology Partners. The models are of two types: o Enterprise Models that depict the entire enterprise and its inter-relationships. o Reference Models that depict recommended & approved technologies & designs, which can serve as a template for future projects. These models cover the following viewpoints: o API Stack of blessed Open Standards and Proprietary Technologies (expanded OSI 7-Layer Model) o Application Map o Data Flow Diagram o Business Process Models (from the Business Process Group) o Logical & Physical Data Schema
© 2008 Knowledge Management. All Rights Reserved.
PAGE 6
Architectural Governance
Page 7
o
Hardware Infrastructure Diagram o Network LAN & VLAN Infrastructure Diagram o Also, where needed to clarify application requirements, Unified Modeling Language (UML) diagrams, viz.: Use Case, Class, Package, Object, Sequence, Collaboration, State-chart, Activity, Component and Deployment Diagrams. Establishes the Design Repository and Metadata Repository for integrating all aspects of these models, and provides oversight of its use in conjunction with integrated Tool sets. Perform design reviews across the organization. (Note: not code reviews.) Leads the evaluation of vendor software targeted for possible integration into the systems or environment, including strategic applications, tools, and utilities. Defines the IT design methodology, development process methodology and best practices. Surveys external emerging developments, and evangelizes new technologies, standards and methodologies that will have a positive impact on the company's bottom-line and quality of service. Participates in external standards body work that defines IT standards in the health community.
Architectural Roles The Architecture team is divided into a number of roles based on an orthogonal “separation of concerns”: Chief Architect Applications Architect Data Architect Information Architect Internet Architect Network Architect Systems Architect Security Architect Process Architect Project Architects (PA) All but the last role comprise the Enterprise Architects. Each role (with the exception of the PA) is focused on issues at the enterprise level and across all projects. Due to the shortage of resources many architects hold more than one of the positions described below. In some cases there
© 2008 Knowledge Management. All Rights Reserved.
PAGE 7
Architectural Governance
Page 8
already exists a central department within the company that has an enterprise focus on one of these roles. In this case the Enterprise Architect may reside in this team and be matrixed into the Architecture team. By this means all architectural work is coordinated across all dimensions and projects.
Responsibilities of Each Architect Chief Architect
Coordinates and facilitates the activity of the Enterprise Architects and Project Architects with existing projects; removing roadblocks where necessary. Takes proactive escalation of probable system problems or design flaws to upper management before serious impact on ROI. Assures the complementary synthesis of all standards, models, designs and methodologies recommended by the Enterprise Architects. Acts as evangelist of the work and recommendations of the architecture team.
Applications Architect
Selects the paradigm and technology for application program-toprogram communication (APPC) among the components. Determines the overall priority ranking of each of the possible system qualities (cost, reusability, robustness, etc.) so the other architects can design models that enforce the “balance of concerns”. Responsible for defining the application tiers, frameworks, components types and interfaces. Also, creates the first-draft graphical template of UML design models used by the Project Architects. Specifies and provides ownership of reusable application components or reusable application code.
Data Architect
Sets Data Policy and the technical solution for the management, storage, access, navigation, movement, and transformation of data. Specifies recommended DBMS and ETL tools and technologies for structured and unstructured content. Creates and maintains the Metadata Repository. Creates a semantically rich business model of the enterprise problem domain that: o Is independent of any technology solution o Defines the Content of the business
© 2008 Knowledge Management. All Rights Reserved.
PAGE 8
Architectural Governance
Page 9
Compiles and maintains the Enterprise Schema across all applications. Enforces principles of good canonical data design. Examines and enforces opportunities to provide data reuse, balancing the issues of centralization and replication. Ensures the preservation of strategic data assets as applications and technologies de jure come and go. Reviews the policies and work of the Data Base Administrators.
Information Architect Because there already exists a central Web Hosting team the Information Architect may reside in this team and be matrixed into the Architecture team. Richard Saul Wurman, the father of information architecture, describes the role in these words: “The individual who organizes the patterns inherent in data, making the complex clear.” “A person who creates the structure or map of information which allows others to find their personal paths to knowledge.” “The emerging 21st century professional occupation addressing the needs of the age focused upon clarity, human understanding, and the science of the organization of information” Defines the visual roadmap seen by the customers of the company with emphasis on making it easy for customers to find the needed data to make appropriate decisions regarding their medical care and management. Establishes branding policy and holds the UI templates. Establishes the personalization policy with a goal to building customer loyalty and relationship enrichment. Defines the recommended dialog flow for long-running transactions and “speech acts” in coordination with the Business Process Group.
Internet Architect
Monitors the emerging standards for B2B & B2C internet interaction and sets the standards and technologies to be used by the enterprise. These include the existing HTML, applet & XML standards, and the emerging web services and semantic net standards. Coordinates with the other architects on issues dealing with the quality flaws of the existing standards, especially security, session state and long-running transactions. Builds a composite reference model to be used on internet-based applications, incorporating the models provided by the system architect, network architect, security architect, and applications architect.
© 2008 Knowledge Management. All Rights Reserved.
PAGE 9
Architectural Governance
Page 10
Network Architect Because there already exists a central Network team the Network Architect may reside in this team and be matrixed into the Architecture team. Focuses on the lower-level transport protocols and the standards and technologies for enabling systems qualities via network command-and-control structures. Evaluates and selects the enterprise’s networking hardware. Manages the network topology. Establishes network operation center (NOC) command-and-control structures for auto-discovery, event monitoring, trouble ticketing. Facilitates the upgrade to the Web-Based Enterprise Management (WBEM) standard of the Distributed Management Task Force (DMTF) and select the appropriate Common Information Model Object Manager (CIMOM) for tracking the state of the enterprises assets.
System Architect
Focuses on the standards and technologies for enabling systems performance qualities, such as availability, scalability, recoverability, etc. Evaluates and selects the enterprise’s server hardware, operating system, job control. Supports the Applications architect in selecting the application framework. Balances the quality issues cost vs. robustness, and hardware architecture, such as share-nothing n-tier vs. share-all symmetric multi-processing (SMP). Monitors performance benchmarks provided by the Transaction Processing Council (TPC). In conjunction with the Project Architect (PA) sizes the application and selects the hardware and configuration to use. Participates in the drafting of Service Level Agreements (SLA). Establishes a process to monitor existing systems for performance problems and drafts system migration plan if necessary.
Security Architect
Monitors security guidelines, such as HIPAA. Establishes and enforces the Security Policy and Trust Model for Administrators to follow in delegating and granting application privileges. Establishes and enforces the Security Model, technologies and standards for system architects and designers.
© 2008 Knowledge Management. All Rights Reserved.
PAGE 10
Architectural Governance
Page 11
Tracks warnings of new types of security threats and assures that the systems in place guard against these threats. Establishes the systems for discovering, tracking and convicting abusers of security and system integrity. Performs periodic security audits on existing systems.
Process/Methodology Architect While the other architects are focused on what the system should contain, the process architect is focused on how the application should be designed and built. Reviews and selects the Design Methodology and Modeling Language. Methodologies may be based on the Zachman, Rational Unified Process (RUP), Catalysis, RM-ODP, Iconix, SAADAM, etc. The modeling language should incorporate the Business Process Model (BPML) and the Unified Modeling Language (UML). Reviews and selects the Process Management Methodology. It is recommended that the new iterative methodologies from the Agile Alliance be reviewed for adoption, esp. Feature-Drive Development (FDD). Defines roles & responsibilities and creates a template Project Plan for modification by Project Managers. Selects CASE & IDE tool & Design Repository. Communicates the above to the development teams, and is enforced by the Project Architects (PA). Manages the education of the PAs.
Project Architects (PA)
Responsible for translating application requirements and business process models (BPM) into component and interface specifications. Ensures that the Technology Partners and development teams adhere to the principles established by the Enterprise Architects. Designs first-draft graphical UML & ER models that are delivered to the software development & DBA teams.
© 2008 Knowledge Management. All Rights Reserved.
PAGE 11
Architectural Governance
Page 12
The activities of the Project Architect (PA) can be contrasted with the Project Manager (PM) as shown in the following table: Topic Software Development
Project Manager Organize project; manage resources, budgets, schedules
Requirements
Negotiate with marketing; emphasis on business process and user interface Handle hiring; performance appraisals, salary; motivate employees Introduce new technologies per architect’s recommendations Ensure quality of product
Personnel issues Technology Quality Metrics
Measure productivity, size, quality
Project Architect Organizes team or technology partner around design; manages dependencies Review requirements; emphasis on functionality and system qualities Interview candidates; provide input on technical capabilities of staff; motivate development team Recommend technology, standards, training, tools Ensure quality of design and operational control characteristics Ensure design goals are met, volumetrics do not exceed scale
© 2008 Knowledge Management. All Rights Reserved.
PAGE 12
Architectural Governance
Page 13
Architectural Stance Architecture Development Process The most fundamental decision that must be made is a ranking of the nonfunctional “qualities” that the systems must support (e.g. availability, security, non-repudiation, etc.). From this follows a determination of open standards and design patterns (frameworks) that will be incorporated into future applications. Next the vendors and products are selected that support the open standards. The set of products must integrate well with each other and align their API Stack to support the design pattern of the selected Application Stack (e.g. n-tier with clearly defined nodes). The tools used by the developers are selected to code, test and debug the application, and then the tools used to design the application is selected with the goal of using clear models to generate clean code for rapid application development (RAD) and model-driven architecture (MDA). The modeling process must conform with the selected development methodology for designing robust code that conforms to the business requirements. Requirements, models, code and test data is kept in a version-controlled Reuse Library that supports traceability and impact analysis showing precise time & budget slippage of a change in requirements. When complete, the above process may iterate to take advantage of low-hanging fruit where it is found that a product has a particularly good synergy with other products. These factors that influence application and development architecture can be show as: Management Methodology
Design Methodology
Design Tools
Development Tools
Architectural Qualities
Standards & Patterns
Application Stack
Requirements, Design, Code, QA Repository
© 2008 Knowledge Management. All Rights Reserved.
PAGE 13
Architectural Governance
Page 14
Architectural Foundations Previous architectural decisions at the enterprise level come into play when designing the architecture for new applications. Application Stack that depict recommended & approved technologies, frameworks and products in support of corporate standards. Reference Models that depict recommended & approved design patterns. Enterprise Models that depict the entire enterprise used to design interfaces between existing applications and the new application.
Target Architectures Architecture Development Method Application Stack (standards)
Reference
Enterprise
Model
Model
Business Requirements & Service Qualities
Application Stack The Application Stack can be represented as a matrix that shows the design tiers (layers) for the application, the open standards API Stack selected, the API stack of vendors and products blessed by the company (for volume purchase and training), the design and development tools used to model the design and generate/edit the source code and debug the application, and administrate and manage the application in the operational environment.
© 2008 Knowledge Management. All Rights Reserved.
PAGE 14
Architectural Governance
Page 15
Here is a partial example of an Application Stack. (This is not a recommendation of these technologies.) Layer
Open Standard
Communi- TCP/IP, HTTP, cation HTML, SSL Application Java, J2EE Data Access Storage Operating System Security
XML, XML Schema Relational, SQL, XML Unix LDAP
Technology Stack Apache
Dev. Tool
Operations Management Smarts, Remedy
WebLogic, JSP, WDK EJB, Documentum Oracle
Eclipse
Smarts, JMX, Remedy
ERwin
BMC
Solaris
Tckl
Smarts
SQLJ
NDS, Netegrity
For multi-tier systems the applications layers are spread over multiple hardware systems, each with their own stack, with the application connected across systems by communication protocol stacks offering a wide array of features in support of the robustness of the application. This can be graphically represented as API stacks that abstract the hardware horizontally and the application over hardware nodes vertically. Here is an example of a 3-tiered application represented across the top of the stack and the hardware interfaces across the bottom of the stack. The invocation and abstraction of the hardware goes down the stack, while the transparent communication protocol is shown touching the relevant components:
© 2008 Knowledge Management. All Rights Reserved.
PAGE 15
Architectural Governance
Page 16
Architectural Layers Application Architecture is an abstract system specification consisting primarily of functional components described in terms of their behaviors and interfaces and component-component interconnections. Each layer in the stack serves as an abstraction to the layer above it. Each layer on the stack must have a set of well defined interfaces that are on the same level of abstraction (that serves some specific purpose). Each layer is responsible for its own sanity check, and typically trusts each of the other layers to do the same unless the data is coming from an external source. Not every layer is used in every transaction. For example, a simple HTML interaction only goes down through the top several layers and then returns. Batch loading from a legacy system may skip several layers. However, if everyone develops their application along a layered architecture then they only have to worry about communication between the layers immediately above and below them. If their layer is sometimes skipped then they must provide a transparent module so the design rule that layers only interact with the layers immediately above and below them remains in effect with few exceptions. Specifying a sequence for top to bottom control flow prevents the problem of cyclic deadlock among objects. Implementation via purchased software packages (even crossing multiple layers) is permitted as long as “wrappers” are coded that can integrate the packaged within the overall architecture and as long as essential administrative control features are present for each layer (e.g. scalable configuration). Breaking the application architecture into a many layered onion facilitates the adaptability of an application while adding to its complexity. Here is an example that calls out most of the possible layers, starting from the customer interface down to the persistent storage:
Customer
Presentation
Transaction
Customer Applications & Applets
Browser, Java applet, Legacy system
Communications
HTTP, ftp, telnet, 3270, EDI, VPN, fax
Access
Security, Certification, Firewall, Encryption, Session Closure, Connection Context
Native Presentation
Layout XML to: HTML, Character, Record layout, EDI (via Templates+Rules), Validation
Generic Presentation
Semantic XML to Layout XML
Workflow Processing
Commerce Events, State Table, Workflow, Job Initiation, Temporal & Priority Control
Application Context
© 2008 Knowledge Management. All Rights Reserved.
PAGE 16
Architectural Governance
Data
Page 17
Application Logic
Custom application-specific code goes here
Business Object
Metadata markup, DB Data
Semantic Navigation
Ontology, Context, KQML, Semantic Undo
Enterprise Schema
Data Dictionary, Referential Integrity
Data Distribution
Heterogeneous navigation, Scale Redirection, Legacy Redirection
DB Transaction
Stored Procedures, ACID
Data View
SQL, Dataset
Physical Data Stores
Index/Cluster Architecture, Bloom Filter, Encryption, RAID
Semantic XML,
Ubiquitous Services Transparently supporting each layer of the communicating objects in the above diagram are the following facilities:
System Framework
Reusability, Interoperability, Accountability, Initiallization
(Communicating Objects)
The above layers go here
XML Dataware
Business Object Access
Middleware Management
Scalability, Messaging, Load Balancing, Monitor, Fail-over, Restart
Directory / Security
DNS, LDAP, X.500
Operating System, Network Protocol
System Administration
Hardware, Wire, Disks
© 2008 Knowledge Management. All Rights Reserved.
PAGE 17
Architectural Governance
Page 18
Non-Functional Quality Requirements The complexity of an application’s functional requirements is not the only driver of system cost. Often cost and complexity is driven by system features that are behind-the-scenes and distributed across all functions of an application, such as “high availability”. These non-functional requirements have a major impact on the architecture of a system. As it is not possible to satisfy all requirements simultaneously trade-offs must be made. Consideration of the selection and weight of each of these qualities is provided in the following table. The non-functional quality requirements for the system is ranked below with a “0” representing a quality that no effort is to be spent on—to—a “10” representing a quality that must be included even if it means additional cost and significantly delaying the release of the system. A “1” represents an optional, nice-to-have, feature. There should be only a few qualities set at “9” or “10”.
Quality
Rank
Business Qualities Affordability: The ability to build the system with minimum development cost in labor and tools.
5
Time-to-Market: The ability to build the system in the minimum amount of time and ahead of competition for the similar functionality.
5
Functionality: The ability of the system to perform all the business tasks it was created to do per the user’s requirements.
7
Regulatory Compliance: Adheres to governmental regulations. Buildability: Whether or not the architecture can reasonably be built using the budget, staff, and time available for delivery of the project. Buildability is an often-overlooked quality attribute. Sometimes, the best architects are simply too ambitious for a project team to complete given project constraints and environment. The design that casts a solution in terms of well-understood concepts is more buildable than a design that introduces new concepts.
© 2008 Knowledge Management. All Rights Reserved.
10
3
PAGE 18
Architectural Governance
Page 19
User Qualities Usability: How easy it is for the user to understand and operate the system. Usability can be broken down into the following areas: Learnability: How quick and easy is it for a user to learn to use the system's interface? Efficiency: Does the system respond with appropriate speed to a user's requests? Memorability: Can the user remember how to do system operations between uses of the system? Error avoidance: Does the system anticipate and prevent common user errors? Error handling: Does the system help the user recover from errors? Satisfaction: Does the system make the user's job easy?
2
Gratification: The ability to anticipate the needs of the user and give more than is asked. Most systems give only what the user specifies and requires the user to expend significant effort in stating the request. A system with gratification learns the user’s habits and preferences, and intervenes with quick solutions or alternatives when the user does not appear to making progress.
2
Localization: The ability easily adapt to multiple languages and locales.
2
Personalization: The ability of a user to adapt the look and feel of the system to their own taste.
3
Customer Compliance: Adheres to the interfaces, data structures and conventions of the customer’s systems without requiring modifications of their systems.
8
Accuracy: Ability to provide the right or agreed results or effects with the needed degree of precision. Includes the ability to resist or correct poor data quality.
8
Mobility: Ability to support mobile devices and cellular communications.
0
Administrator Qualities Manageability: Can be expressed in terms of how easy it is to monitor a system and detect operational characteristics related to performance and failures, how easy it is to configure systems, the processes used for effecting this control, and the degree to which the system can be managed remotely.
3
Administrability: Can be expressed in terms of how easy it is to configure an application and detect application characteristics related to functional usage, how easy it is to configure the application, the processes used for effecting this control, and the degree to which the application can be administered by multiple parties in cooperating roles.
7
Data Location Transparency: The business logic layer of the application does not know the physical location of the data. The data may be distributed to multiple locations at sites determined by the DBAs and administrators for tuning, fail-over, and storage resource control.
8
© 2008 Knowledge Management. All Rights Reserved.
PAGE 19
Architectural Governance
Page 20
Component Location Transparency: A client does not know where a target server object resides. It could reside in a different process on another machine across the network, on the same machine but in a different process, or within the same process. Different components can be distributed over multiple machines, or, copies of the same component can be distributed over multiple machines.
7
Implementation Transparency: A client neither knows how a target object is implemented, what programming or scripting language it was written in, nor the operating system and hardware it executes on. This is also a security issue.
2
Hardware Virtualization: The application may be moved unchanged as compiled from the testing to the operational environment and across multiple hardware environments. VMware is an example of such an approach.
1
Object (Server) State Transparency: When a client makes a request on a target server object, it does not need to know whether that object is currently activated (i.e. in the executing state) and ready to accept requests or not. The ORB transparently starts the object if necessary before delivering the request to it. This feature greatly helps recovery handling for distributed objects.
3
Communication Mechanism Transparency: A client does not know what communication mechanism (e.g., TCP/IP, shared memory, local method call, etc.) the ORB uses to deliver the request to the object and return the response to the client. Multiple communication strategies may be statically or dynamically set.
2
Security: The ability of the system to resist unauthorized attempts to access the system and denial-of-service attacks while still providing services to authorized users. Includes levels of authentication supported, granularity of authorization controls, and techniques utilized to ensure the integrity of resources.
9
Auditability: The ability to ensure that the previous system states can later be reconstructed and observed. Includes recording and analyzing activities to detect intrusions or abuses.
9
Accountability: The ability to ensure that the ultimate causes of the previous system states can later be identified. The ability to know who did what.
8
Confidentiality: keeping information secret only to those who are authorized to see it.
9
Anonymity: concealing the identity of an entity involved in a process.
3
Privacy: Ability to follow business rules in regard to the rights and responsibilities that govern the acquisition, disclosure, and use of personal information.
9
Data Integrity: ensuring information has not been altered by unauthorized means.
9
Data Authentication: corroborating the source of data
7
Access Control: restricting access to resources to authorized entities.
8
Non-Repudiation: The ability to provide legally accepted proof that a user executed a particular transaction, even if they deny having done it. Must be able to discriminate against spoofing and man-in-the-middle attacks.
5
© 2008 Knowledge Management. All Rights Reserved.
PAGE 20
Architectural Governance
Page 21
Qualities of Service Quality of Service (QoS): The ability to measure and stay within the guaranteed performance and availability limits for contracted services per SLA.
4
Scalability: The ability for the system to grow linearly by adding hardware as the number of users and transactions increase beyond initial implementation. For high scalability you typically need: Asynchronicity Statelessness Parallelism Pipelining Location Transparency Load Balancing GUIDs
5
Performance: A specification of the workload and the latency or throughput requirement. The form of the specification will depend on the type of system. In an interactive system, the form of the specification might be an abstract specification of the number of users and a deadline for response; in an embedded real-time system, the form of the specification might be a characterization of the input events and an associated deadline.
6
Responsiveness: A measurement of the system response time for a functional requirement.
6
Availability: The amount of time that the system is up and running. It is measured by the length of time between failures, as well as by how quickly the system is able to restart operations after a failure. For example, if the system was down for one day out of the last twenty, the availability of the system for the twenty days is 19/19+1 or 95 percent availability. This quality attribute is closely related to reliability. The more reliable a system is, the more available the system will be. The rule of thumb is that each additional “9” of availability raises system cost ten-fold.
7 99.9%
Survivability: The ability to reestablish operations after a catastrophic event that leaves all existing systems unusable.
8
Reliability: The ability of the system to operate over time. Reliability is measured by the mean-time-to-failure of the system.
8
Recoverability: The ability to resume operations after a hardware or software fault that halts the current systems. Is expressed by: 1. Capability to reestablish the level of performance. 2. Capability to recover the data. 3. Time and effort needed for it. Measured by Mean-Time-To-Repair.
7
Nomadicity: Having components (or mobile agents) that can survive relocation of the component and/or automatically discover alternative living peer components in the event that the peer components it was communicating with fail, or can continue to work without interruption should related components fail. The DNS internet, Microsoft Outlook/Exchange, and cellular phone system are examples of nomadic systems. Service Oriented Architecture (SOA) using UDDI can easily be made nomadic.
1
© 2008 Knowledge Management. All Rights Reserved.
PAGE 21
Architectural Governance
Page 22
Autonomic Computing: Autonomic computing derives its name from the autonomic nervous system and denotes its ability to free our conscious brains from the burden of dealing with the vital, but lower-level, functions of the body. As used in the software industry, autonomic computing refers to self-managing systems that are comprised of four core characteristics: self-configuration, self-healing, self-optimizing, and self-protecting. Transactionality: The ability to commit a unit of work or, in the case of an error, rollback the data across all tables and stores. To be transactional all of the ACID constraints (qualities) must be met: Atomic: all or nothing Consistent: logically correct transformation Isolated: no concurrency bugs Durable: survives failures
8
Software Life-Cycle Qualities Evolvability: The ability of a system to change over time with minimum phased cutover impact.
3
Composability: The ability to sell the system as separate components that can work on their own or together in harmony.
5
Extensibility: The ability to easily add new data and behaviors to existing code by the developers.
7
Tailorability: The ability easily adapt the system to the needs of a specific customer. Includes the ability to re-brand the user interface. Minimizes the effort needed to maintain separate code bases.
6
Adaptability: The ability to define business processes, business rules and refine data types by an application administrator dynamically, without needing code revision.
9
Maintainability: The measurement of how easy it is to change the' system to incorporate new requirements. The two aspects of' modifiability are cost and time. If a system uses an obscure technology that requires high-priced consultants, even though it may be quick to change, its maintainability can still be low.
3
Portability: Measures the ease with which the system can be moved to different platforms. The platform may consist of hardware, operating system, application server software, or database server software.
7
Reusability: The ability to reuse portions of the system in other applications. Reusability comes in many forms. The run-time platform, source code, libraries, components, operations, and processes are all candidates for reuse in other applications.
2
© 2008 Knowledge Management. All Rights Reserved.
PAGE 22
Architectural Governance
Page 23
Integrability: The ability to make the separately developed components of the system work correctly together as a whole. This in turn depends on the external complexity of the components, their interaction mechanisms and protocols, and the degree to which responsibilities have been cleanly partitioned, all architecture-level issues. Integrability also depends upon how well and completely the interfaces to the components have been specified. Integrating a component depends not only on the interaction mechanisms used (e.g., procedure call versus process spawning) but also on the functionality assigned to the component to be integrated and how that functionality is related to the functionality of this new component's environment.
6
Interoperability: Integrability measures the ability of parts of a system to work together; interoperability measures the ability of a group of parts (constituting a system) to work with another external system. The integrability of a system depends on the extent to which the system uses open integration standards and how well the API is designed such that other systems can use the components of the system being built
7
Testability: The ease with which software can be made to demonstrate its faults through testing (probability that the software will fail on its next test, given that it has at least one fault). How easily the system can be tested using human effort, automated testing tools, inspections, and other means of testing system quality. Good testability is related to the modularity of the system. If the system is composed of components with well-defined interfaces, its testability should be good.
3
Variability: How well the architecture can handle new requirements. Variability comes in several forms. New requirements may be planned or unplanned. At development time, the system source code might be easy to extend to perform new functions. At run-time, the system might allow pluggable components that modify system behavior on the fly. This quality attribute is closely related to modifiability.
3
Subsetability: The ability of the system to support a subset of the features required by the system. For incremental development, it is important that a system can execute some functionality to demonstrate small iterations during product development. It is the property of the system that allows it to build and execute a small set of features and to add features over time until the entire system is built. This is an important property if the time or resources on the project are cut. If the subsetability of the architecture is high, a subset of features may still make it into production.
7
Conceptual Integrity: The ability of the architecture to communicate a clear, concise vision for the system, also know as Architectural Style. Fred Brooks writes, “I am more convinced than ever. Conceptual integrity is central to product quality. Having a system architect is the most important single step toward conceptual integrity…. After teaching a software engineering laboratory more than 20 times, I came to insist that student teams as small as four people choose a manager and a separate architect” (Brooks 1995). Kent Beck believes that metaphors are the most important part of the eXtreme Programming methodology (Beck 1999). The metaphor is a powerful means of providing one or more central concepts for a system. The metaphor provides a common vision and a shared vocabulary for all system stakeholders. The metaphor provides a means to enforce conceptual integrity. When the design of the system goes outside the bounds of the metaphor, the metaphor must change or new metaphors must be added; otherwise, the design is going in the wrong direction. If any of these design decisions are made without the concept feeling right, the conceptual integrity of the system will be lost. Sometimes the system metaphor is an architectural pattern, such as MVC or Blackboard. These architectural patterns provide a common metaphor for system developers or others who understand the patterns.
5
© 2008 Knowledge Management. All Rights Reserved.
PAGE 23
Architectural Governance
Page 24
Non-obsolescence: If the system is intended to have a long lifetime, modifiability and portability across different platforms become important, as well as rejection of technologies that may become obsolete and vendors that may go out of business. Building in the additional infrastructure (such as a portability layer) to support modifiability and portability will usually compromise time to market. On the other hand, a modifiable, extensible product is more likely to survive longer in the marketplace, extending its lifetime.
6
Installability: The capability of the software product to be installed in a specified environment.
7
Co-existence: The capability of the software product to co-exist with other independent software in a common environment, sharing common resources.
1
Replaceability: The capability of the software product to be used in place of another specified software product for the same purpose in the same environment.
2
Standards Compliance: Adheres to external open standards.
7
The following qualities are absent from this list and may be added later if needed: flexibility, understandability, deployability, configurability, degradability, accessibility, demonstrability, footprint, simplicity, stability, timeliness, schedulability, openness, seamlessness, safety, trust, Error, Multi-Undo, feedback, empowerment
© 2008 Knowledge Management. All Rights Reserved.
PAGE 24
Related Documents
Architectural Governance
December 2019 19
Architectural
May 2020 33
Architectural Drawing.pdf
November 2019 26
Governance
October 2019 40
Architectural 20080309
November 2019 25