Citywide Enterprise Architecture Framework and Methods

Citywide Enterprise Architecture

Framework and Methods V1.0

Anthony Insolia

Director, Enterprise Architecture City of New York Department of

Information Technology and Telecommunications, Chief Technology Office

___________________________________________________________ This document was created by the Chief Technology Office of the Department of Information Technology and Telecommunications (DoITT) to describe the Citywide Enterprise Architecture Framework of the City of New York, define the Citywide Enterprise Architecture policy, and outline its benefits for City governance. The primary audiences for this document are City agency Chief Information Officers and Chief Architects who will develop architectures using industry standard methods as described in the Citywide Enterprise Architecture Framework. The City of New York is hereafter referred to as NYC or the City.

For Official Use Only 11/21/08

CONTENTS

EXECUTIVE SUMMARY................................................................................................................. iv THE NEA AND ITS USES ............................................................................................................... 1

NYC Enterprise Architecture (NEA) Defined ............................................................................... 2 NYC Enterprise and Portfolio Defined ......................................................................................... 4 Building the NEA.......................................................................................................................... 5 Building the Enterprise................................................................................................................. 7 Using the Architecture.................................................................................................................. 9

FRAMEWORK............................................................................................................................... 10 Zachman Framework ................................................................................................................. 10 Department of Defense Architecture Framework (DoDAF) ....................................................... 11 Federal Enterprise Architecture Framework (FEAF) ................................................................. 11 The NEA Framework (NEAF) .................................................................................................... 13

What We Took From Zachman .............................................................................................. 13 What We Took From the DoDAF ........................................................................................... 14 What We Took From the FEAF.............................................................................................. 15 What the NEAF-Based Architecture Looks Like .................................................................... 15

ARCHITECTURE DIAGRAMS ...................................................................................................... 18 The Diagram as a Painting Canvas ........................................................................................... 18 The Paint.................................................................................................................................... 18 The Artifacts ............................................................................................................................... 18 The Diagrams............................................................................................................................. 19

Overview Diagrams ................................................................................................................ 19 Capability Overview ............................................................................................................ 19 Dictionary............................................................................................................................ 20 Maturity Model .................................................................................................................... 20 Business Case.................................................................................................................... 20 Requirements ..................................................................................................................... 21

Operational Diagrams ............................................................................................................ 21 Operational Concept and Vision......................................................................................... 21 Operational Node/User Group Connectivity ....................................................................... 22 Capability and Service Taxonomy ...................................................................................... 22 Service-to-Process Mapping............................................................................................... 22 Organizational Structure ..................................................................................................... 23 Organizational Staffing ....................................................................................................... 23 Process Taxonomy ............................................................................................................. 23

For Official Use Only 11/21/08 ii

Process Context and Performance..................................................................................... 23 Process Information Flow ................................................................................................... 24 Business Rules ................................................................................................................... 24 Process Details................................................................................................................... 24 Capability and Services Training ........................................................................................ 25 Data Model.......................................................................................................................... 25 Data State........................................................................................................................... 25 XML Representation of Data .............................................................................................. 25

Systems Architecture Diagrams............................................................................................. 25 System Interface Description.............................................................................................. 26 System Communications Description................................................................................. 26 Application Portfolio Performance ...................................................................................... 26 System Evolution Description............................................................................................. 26 Sequence............................................................................................................................ 27

Technical Standards Architecture Diagrams.......................................................................... 27 Technical Standards Profile................................................................................................ 27 Technical Standards Forecast............................................................................................ 27

METHODS..................................................................................................................................... 28 Unified Modeling Language (UML) ............................................................................................ 28 Integrated Definition (IDEF) Family ........................................................................................... 28 Activity-Based Costing (ABC) .................................................................................................... 29 Business Process Modeling Notation (BPMN) .......................................................................... 30 Department of Defense (DoD) Architecture Methods................................................................ 30 Diagram/Method Mapping.......................................................................................................... 31

NEXT STEPS ................................................................................................................................ 32 APPENDIX..................................................................................................................................... 34

Related Documents ................................................................................................................... 34 NEA Document Set.................................................................................................................... 34 Role Definitions.......................................................................................................................... 35

Chief Architect ........................................................................................................................ 35 Responsibilities................................................................................................................... 35 Qualifications ...................................................................................................................... 35

Enterprise Architect ................................................................................................................ 36 Responsibilities................................................................................................................... 36 Qualifications ...................................................................................................................... 36

Sample Solicitation Language ................................................................................................... 36 Glossary ..................................................................................................................................... 37

For Official Use Only 11/21/08 iii

EXECUTIVE SUMMARY The Citywide Enterprise Architecture (NEA) is an executive-level discipline and tool that facilitates City business planning performed at the Mayoral, Deputy Mayoral (Line of Business), Agency, and Program levels. It does this by getting specific about the costs of current business operations and the benefits of new business models and technology enablers, and by providing methods for documenting costs and benefits.

Architecture enables the City to use capability-based portfolio management. Capability-based portfolio management means viewing City government as a single enterprise with a comprehensive set of capabilities, which are capacities to manage and deliver services.1 Architecture is simply a way to blueprint a structure or system, whether a building, a business, or a capability. The framework we present is a set of specifications for creating those blueprints, using industry-standard approaches to gathering information about capabilities.

Architecting the City’s portfolio of capabilities promotes a deeper understanding of the costs, risks, and performance of City activities.

Two triggers initiate the collection of architecture information: portfolio gaps and portfolio issues. Portfolio gaps are missing capabilities, while portfolio issues are problems with existing capabilities.

Architecture quantifies and qualifies gaps and analyzes industry offerings to create blueprints that document how the gaps should be addressed.

Architects also analyze existing blueprints to pinpoint issues and to check for the fit and finish of solutions to the issues.

In both cases, whether gaps or issues are identified, architecture creates portfolio recommendations and transition plans that support informed funding decisions.

Enterprise Architecture is based on thhomeowners as clients engage architthe architects transform their requiremengineers and constructed by builderenterprise architects gather informatiospecify requirements and business ruThe diagrams of the enterprise architWhether architecting a business or a understand the cost, facilitate informefrom the builders. Figure 1 shows thisgathered on the blueprints is being pl

1 ITIL Glossary of Terms and Definitions,

eece

s.nleechod bac

IT

Figure 1. Architecting a house or a business

metaphor of traditional building architecture. Prospective ts to gather information about their ideas for a house, and nts into specific plans that can then be designed by The architect’s plans are blueprints. In the same way, from business owners about desired capabilities to s, which are used to develop scoping and needs analyses. t correspond to the blueprints of the building architect. use, plans and costing models are necessary to

decisions, and ensure that owners get what they want asic process and its flow where the information being ed in the Architecture Repository. This repository

IL V3 Glossary, v01, 30 May 2007

For Official Use Only 11/21/08 iv

becomes the source of record for strategic plans, operational aspects of NYC as a business, and the underlying IT infrastructure supporting the business. More importantly, this repository becomes a baton that is passed off from administration to administration. This repository is depicted again in Figure 2 to show that architecture information is being gathered in numerous systems and without regard for data standardization. Just as the American Institute of Architects (AIA) 2 provides standards for architecting buildings, the Citywide Enterprise Architecture Framework (NEAF) provides the standards for architecting the City as a business and ensuring that what is built is aligned with strategic goals and objectives as defined in PlanIT3, the Citywide Performance Reporting System (CPR), and other planning tools.

The NEA combines the architecture information into a federated Citywide structure and repository that defines the mission, goals, and objectives of the City as an enterprise. The NEA defines the people, processes, information, and tools needed to perform the City’s mission. It defines the plans for implementing technologies to support that mission and achieve the goals and objectives of City governance.

Enterprise Architects use the framework to architect capabilities for business owners. The NEA contains the blueprints with the appropriate level of costing information that the Office of Management and Budget (OMB) needs to approve investments in new capabilities or in the augmentation of existing capabilities.

The NEA is therefore a planning and investment management tool. The NEAF is the basis for gathering, organizing, and depicting information about current City functions to undertake a rigorous analysis of the risks, benefits, and alternatives when planning all transformations of current activitieswith deep levels of specificity embeplanning, which drives down costs acontracts, and business maturity.

Architecture enables City governmeassets. It saves time, saves moneyand increases the coordination andactivities. As an example, the City sNEA has blueprints that document trediscovery.

2 The American Institute of Architects (A http://www.aia.org/about_default 3 PlanIT, New York City Technology Pla

addn

y

n, r oah

I

n

Figure 2. Architecture Repositor
nd future development. The NEA displays the information ed in diagrams. This enables greater rationalization of d improves the management of investments, suppliers, risk,
t to take fuller advantage of existing infrastructure and educes risks, ensures program alignment with City missions, versight of a continuing process of improving all City ves money every time a supplier is engaged because the e operational and systems landscapes, which reduces

A): About the AIA

For Official Use Only 11/21/08 v

The NEA is relevant in the following management areas: Investment/Portfolio Management: The NEA simplifies the OMB evaluation of portfolio

recommendations by creating a standardized approach for analyzing and recording alternatives, identifying reuse opportunities, eliminating redundancy, developing business cases, managing costs, and preventing duplicate effort. It also provides OMB with an inventory of capabilities, services, and processes, and a catalog of standards and preferred providers for reference purposes when funding requests are being evaluated. Following the maxim “Architect once, deploy many,” the NEA solves problems as a class instead of individually. For example, it is much more efficient and cost effective to architect one service delivery center than 26 data centers.

Contract Management: The NEA helps achieve consistency in contracts. It allows reuse of processes and information to enhance delivery and quality and drive costs down.

Supplier Management: The NEA defines activities, tasks, methods, work products, and deliverables. Architecture also eliminates rediscovery costs by recording information in standardized form.

Risk Management: The NEA reduces risk for Program Managers by formalizing and standardizing the program management process.

Maturity Management: The NEA helps the City mature as an enterprise by standardizing processes, monitoring performance, and making adjustments based on NEA feedback.

The NEA views the City as one enterprise with one architecture. The NEA is more than just Information Technology (IT). It is a repository for information about all City business operations. It belongs to the whole City and is platform and vendor neutral.

For Official Use Only 11/21/08 vi

THE NEA AND ITS USES In 1996 the Federal government established the Information Technology Management Reform Act (ITMRA, now the Clinger-Cohen Act), 4 which was designed to help the Federal government, as an enterprise, align and manage investments and government-wide capabilities. Subsequently, on October 25th, 1996, Franklin Raines, then director of the Office of Management and Budget, issued a memorandum with the subject line "Funding Information Systems Investments." The memo was quickly renamed “Raines' Rules” 5 and became a seminal document for guiding how agencies purchase information technology. The rules, as outlined in the memo, specify that investments in major information systems proposed for funding should:

1. Support core/priority mission functions that need to be performed by the Federal government. 2. Be undertaken because no alternative private sector or governmental source can efficiently support

the function. 3. Support work processes that have been simplified or otherwise redesigned to reduce costs,

improve effectiveness, and make maximum use of commercial off-the-shelf (COTS) technology. 4. Demonstrate a projected return on investment that is clearly equal to or better than alternative uses

of available resources. 5. Be consistent with Federal, agency, and bureau information architectures which: integrate agency

work processes and information flows with technology to achieve the agency's strategic goals... and specify standards that enable information exchange and resource sharing, while retaining flexibility in the choice of suppliers and in the design of local work processes.

6. Reduce risk by: avoiding or isolating custom-designed components ...; using fully tested pilots, simulations, and prototypes ...; establishing clear measures and accountability for project progress; and securing substantial involvement and buy-in ... from program officials who will use the system.

7. Be implemented in phased, successive chunks as narrow in scope and brief in duration as practicable, each of which solves a specific part of an overall mission problem and delivers a measurable net benefit independent of future chunks.

8. Employ an acquisition strategy that appropriately allocates risk between government and the contractor, effectively uses competition, ties contract payments to accomplishments, and takes maximum advantage of commercial technology.

Any proposed investment should be questioned to determine whether each of these eight Raines’ Rules has been addressed. The NEA is designed to be the source of record for the information required to answer those questions.

To understand the scope of the NEA and how to use it to answer these questions, we start with some basic definitions including the definition of enterprise and architecture.

An enterprise is an organization supporting a defined business scope and mission, including interdependent resources (policy, organization, training, systems, people, processes, tools, leadership, and facilities) that must coordinate their functions and share information to support a common set of interrelated missions.6 The government of the City can be viewed as a single enterprise, starting with the Mayor and Deputy Mayors, and including all the agencies, City-chartered public authorities, elected officials, public-benefit corporations, community boards, cultural institutions, and all other entities undertaking City governmental business operations.

Architecture is a way to blueprint a structure or system, whether a building or a business. A framework is a specification and set of standards for creating blueprints. A method is an

4 Public Law No. 104-208 of 1996, National Defense Authorization Act , Division E - Information Technology Management Reform (Clinger/Cohen Act) 5 OMB Memorandum of October 25, 1996, Subject: Funding Information Systems Investments 6 A Practical Guide to Federal Enterprise Architecture (Chief Information Officer Council, Version 1.0, February 2001)

For Official Use Only 11/21/08 1

organized body of techniques for gathering information, integrating or correcting previous information, and applying a systematic approach to the design and construction of architecture diagrams to encompass and express that information. Enterprise Architecture (EA) is a strategic information asset base that defines the enterprise’s mission, information necessary to perform the mission, and the plans for implementing technologies to support that mission and to respond to changing mission needs.7

The NEA and the NEA Framework and Methods are applied to clarify and document operational aspects of the City as a business or enterprise, and the underlying materiel, facilities, and information technology that support it. The Citywide Enterprise Architecture is created by applying the NEA Framework and Methods to the City.

The NEA and the NEAF are based on three industry-standard frameworks and five methods for the architecture business capabilities. The frameworks are the Zachman Framework, the Federal Enterprise Architecture Framework (FEAF), and the Department of Defense Architecture Framework (DoDAF). The methods are the Unified Modeling Language (UML), the Integrated Definition Language (IDEF), the Business Process Modeling Notation (BPMN), the methods of the Department of Defense Architecture Framework (DoDAF), and Activity-Based Costing.

The architect views City government from a portfolio management perspective, as a collection of Lines of Business and capabilities. In this view, the enterprise called the City has a portfolio of capabilities that are provided by programs that acquire and/or develop systems that run applications that automate processes. The capabilities are associated with Goals, Objectives, and Strategies, and can cross the boundaries of the agencies and other organized bodies. Viewing the City as an enterprise in this way provides a simplified and comprehensive vision of the City that facilitates Citywide Portfolio Management.

NYC Enterprise Architecture (NEA) Defined The enterprise called City government traditionally has been viewed as a collection of agencies

NYC, one City

is divided into five boroughs

NYC government, one enterprise

is divided into ten Lines of Business

Figure 3. NYC Boroughs as zones Figure 4. Lines of Business as zones

7 A Practical Guide to Federal Enterprise Architecture (Chief Information Officer Council, Version 1.0)


and other organized bodies such as councils, commissions, boards, departments, and similar official entities. This view is shown by standard organization charts. From this outlook, agency services are often seen as isolated projects. The Mayoral goals of accessibility, transparency and accountability, however, promote an alternative view of City government from a portfolio management perspective, which is the Line of Business view described above. This is the perspective of the Enterprise Architect.

Enterprise Architects use the building architecture metaphor to describe the people, processes, and tools used to ensure that the structure of an organization is sound from both a technological and a business perspective. In the architecture and design of buildings, architects and engineers design buildings that fit within building zones and satisfy zoning ordinances. The NEA architects

cBIscbbfCL

Wbd

example, they might create a sketch of a two-story hoarchitects specify the size, shape, and intent of the buscope of the building. Next they create diagrams that water, and telephone service are provided to the build

Figure 5. Zone and building information

For Offic

apabilities for the City that fit within Lines of usiness and that satisfy mission objectives.

n the same way that the AIA promulgates tandards for building design and onstruction that the City enforces though uilding codes in different zones of the five oroughs, the NEAF establishes standards or architecting business operations both itywide and within the zones of the ten ines of Business.

hen architects plan for the construction of uildings, they begin with models and iagrams of the proposed building. For me on the corner of a residential street. The ilding. In effect, they are determining the show the structure and how electricity, heat, ing. Then they continue to drill down, in a

Figure 6. Line of Business (zone) and capability information

ial Use Only 11/21/08 3

process known as progressive elaboration, until they have all the AIA-compliant drawings that can be used by all the people involved in constructing the building.

Similarly, Enterprise Architects plan for the construction of business capabilities. A business capability is the equivalent of a building in the architecture metaphor. In architecting enterprises, the architects must first zone the enterprise. In NYC, the enterprise is broken down into Lines of Business that own business capabilities. Figures 3 and 4 depict the zoning of NYC business operations into ten Lines of Business, and show how this subdivision of the enterprise is analogous to the subdivision of the City into boroughs.

In architecting the enterprise, the architects begin with an understanding of the portfolio of capabilities and the understanding that architecture diagrams for each capability exist in printed or machine-readable form. Of course, the architects are not concerned with bricks and mortar, but rather with people and processes. Nevertheless, the approach is the same. The enterprise architects begin with a general framework as the specification for what diagrams need to be created and what information is required for each diagram. The architects then create the diagrams and add detail in an iterative fashion using the Citywide architecture tools provided by the NEA Program (NEAP) operated by DoITT.

In the same way that the City collects information about building architecture and enforces building codes, enterprise architecture collects information about Line of Business capabilities and ensures that standards are developed and business rules are followed in the design and construction of new capabilities. Figures 5 and 6 depict the capabilities of one Line of Business, and show how this organization is analogous to the organization of building information.

The inventory of information gathered about Citywide-, Line of Business-, and Agency-specific capabilities is described in later sections of this document.

The NEA functions as a repository for information that defines the mission, goals, and objectives of the City. It defines the needed people, processes, information, and tools, and the plans for implementing technologies to support that mission. The NEA ensures that the business operations that are built align with strategic goals and objectives. More than just IT, the NEA is a repository for information about all City business operations. It belongs to the whole City and is platform and vendor neutral.

NYC Enterprise and Portfolio Defined The enterprise called the City is a group of more than forty agencies that supplies services to the public and runs the City. These agencies collectively represent ten Lines of Business (LOBs), or areas of support, for the citizens of New York, who can be seen as customers of the enterprise. LOBs are cross-agency collaborations that reflect communities of interest rather than organizational partitions. The City Lines of Businesses are as follows:

Customer Service: This LOB is concerned with improving government programs by the use of technology and process reengineering to communicate better internally and with the public, and to increase the options available to the public to access services.

Economic Development: This LOB centers on improving the long-term financial stability of the City by improving financial management, collaboration, and efficiency; streamlining and automating support systems for new businesses; improving job training and placement tools and programs; and considering the environmental impact of economic decisions.

Public Safety: This LOB includes agencies that protect the citizens of New York, namely, the Police and Fire Departments, Emergency Medical Services, and the Office of Emergency Management.

Health and Human Services: This LOB is responsible for ensuring the City provides medical and related services, including food and shelter, employment, and child care, to those New Yorkers in need of assistance.

Education: This LOB focuses on the intellectual development of New Yorkers, with an emphasis on the children.


Community Services: This LOB serves to maintain and improve the cultural and recreational facilities in the City.

City Infrastructure: This LOB encompasses agencies that plan, design, construct, and maintain the City’s transportation network, water and wastewater facilities, and City-owned buildings.

Citywide Administration: This LOB represents the continual effort to improve efficiency and reduce the cost of City government by increasing the amount of automation.

Legal Affairs: This LOB handles issues related to City, State, and Federal laws and regulations.

Foundational Information Technology: This LOB comprises the supporting technology to enable all the other LOBs, and focuses on computer applications, telecommunications, and records and information management.

These LOBs define the zones and zoning map of the City as an enterprise. The Agencies that fall within these Lines of Business are the organization units that are funded to architect and deliver three types of capabilities in the portfolio:

Citywide capabilities that span Line of Business boundaries. These capabilities provide services to the public while providing for the Mayoral goal of transparency. They do this by treating the Lines of Business as trading partners with information exchange requirements that make the Lines of Business and the underlying agency boundaries transparent to the public. An example is the Citywide Licensing and Permitting capability being delivered by the Business Express program positioned within the Department of Small Business Services (SBS).

Line of Business-specific capabilities that span agency boundaries. An example is the Public Safety Line of Business capability called Emergency Public Communication being delivered by the Notify NYC program owned and operated by the Office of Emergency Management (OEM).

Agency-specific capabilities such as the Inmate Custody Management capability of the Department of Correction (DOC).

All three types of capabilities require blueprints that articulate the current (“as-is”) environment, the proposed (“to-be”) environment, a transition plan, and a business case.

Building the NEA As explained above, the NEA views City government from a portfolio management perspective. The portfolio is a collection of capabilities associated with goals, objectives and strategies for achieving goals and objectives. Since the portfolio of capabilities includes Citywide, Line of Business-specific, or Agency-specific capabilities, the NEA divides NYC Business Operations into a Citywide section, a Line of Business section, and a section to accommodate all Agency-specific capabilities. Viewing City functions in this way can provide an unimpeded, less fragmented, and more comprehensive view of City activities.

The NEA is built one capability at a time and one perspective at a time. Everyone in the enterprise contributes to the building of the NEA. Deputy Mayors and Agencies produce a Mayor’s view of the enterprise on behalf of the Mayor. Figure 7 shows the Mayor’s view of the Citywide portfolio. The Mayor’s view divides the City into LOBs, records the dependencies between Lines of Business, and details Citywide capabilities. Deputy Mayors also develop LOB views of the enterprise. Figure 8 shows the Deputy Mayoral view of a LOB as a collection of capabilities. Agency Commissioners and Chief Information Officers provide Agency-specific and program-specific views containing detail suitable for systems integrators to engineer end-to-end solutions. Systems integrators provide the engineering and integration detail and subcontractors deliver piece parts and information about the environment “as built” when it varies from the architecture or plan.

Building the architecture starts with the Deputy Mayors knowing what capabilities, gaps (missing capabilities) and issues (problems with existing capabilities) are present in the portion of the enterprise for which they are responsible and understanding the dependencies that they have on others in the enterprise. This is the Strategic Planning process. In architecture terms, strategic plans are lists of capabilities that are aligned with strategic goals and objectives. Existing


capabilities have known operational costs and expected lifespans. New capabilities are established to fill gaps. Workgroups are formed to analyze the gaps and architect the capability to fill the gaps. The strategic planning process and the execution of architecture activities and tasks are triggered by two possible business events: gaps and issues.

The NEA is a byproduct of the program life cycle and its processes, which are prompted by these triggers. Architecture information is produced before programs are started to ensure that the proposed capabilities are aligned with goals and objectives and that they do not already exist, and during the life of a program to formalize the analysis of alternatives (AoA).

One of the purposes of architecture is to supply a foundation for the delivery of portfolio recommendations and AoA. Figure 9 shows the life cycle for an acquisition program. Architecture activities, tasks, work products, deliverables, methods, and roles are applied within a standard set of program phases. The AoA is shown along with the phases of the program, and the milestones that enable the governance process and architecture reviews.

The program life cycle depicted in Figure 9 outlines the phases of program management. The program life cycle provides the underpinnings of the governance process, and frames the architecture activities and tasks that result in standard architecture work products and deliverables. The work products and deliverables are required at the milestones depicted as diamonds.

The architecture information about a capability is continually gathered and refined. The architecture description is a representation of a current or postulated “real-world” configuration of resources, rules, and relationships that enables the City to manage

IT efficiently as a strategic resource and business-process enabler. In this way, the NEA directs informed decision-making and helps to mature the enterprise.

Developing architecture is a process of gathering information to define and document specific attributes of the capabilities and their programs. As the information is gathered and the programs and processes are diagrammed, the information that is gathered is collected in the

repository called the Architecture Repository. This is illustrated by Figure 10.

To the Deputy Mayors, the portfolios for each Line of Business are a collection of capabilities

To the Mayor, the City’s portfolio

is divided into ten Lines of Business

Figure 7. Mayor’s (Citywide) portfolio Figure 8. Deputy Mayor (Line of Business) portfolio

The architecture that is produced is the result of architecture activities and tasks embedded in the program management process. Programs executing the program management process perform


the analysis and develop NEAF-compliant documentation and blueprints for capabilities in the City’s portfolio. As the information is collected and diagrammed, gaps and issues become more apparent, as well as opportunities to avoid redundancies of effort and leverage the reuse of existing resources.

Workgroups operating under the auspices of the Portfolio Management Advisory Council (PMAC) ensure that for each capability the following information is captured:

Figure 9. Program Lifecycle

Goals, objectives, and performance measures aligned with Mayoral goals and objectives

The list of data and authoritative sources within scope

The list of services and processes within scope

The list of physical locations that need to be considered

The list of parties, agencies, and user communities to be considered

Timing considerations and business events that are in scope

The list of policies and legal mandates that direct and constrain the capability.

The result is the creation of a strategic plan, with a Mayor’s view of each capability and an associated portfolio recommendation. Portfolio recommendations based on architecture analysis and including Mayoral-view detail are provided to the Chief Information Officer (CIO) Council.

Figure 10. Repository Tool

Building the Enterprise In NYC, ideas are turned into reality through a methodical approach at the heart of which is a quality-control process. The Portfolio Management Advisory Council (PMAC), which is composed of the Deputy Mayors and other leaders, has a program and project technical-review process using the Project Approval Form (PAF). The PAF is intended to ensure that plans for all new or significantly changed capabilities are adequately architected and reviewed before they are funded and implemented. The process establishes several quality gates that measure the prospective


program’s adherence to policies and standards in the functional areas of Security, Enterprise Architecture, Network Policy, Information Utility, and Application Development.

Agencies and the programs they own are responsible for capabilities directly associated with prioritized strategic goals and objectives. Programs are launched based on functional needs and area analysis performed using architecture methods. Some of the information required to lay the foundation and to perform the AoA is in the PAF. The PAF tells the story of the capability and provides the business case as justification to put the capability into the strategic plan and launch the program.

In creating the architecture-based PAF, the program has already executed a portion of the concept phase, and a piece of the architecture is then complete. The program next has to go deeper into the architecture of the capability to establish more specific detail.

Figure 11 shows an overall view of a Line of Business as a portfolio of capabilities comprised of

pf1c
Figure 11. Enterprise Lifecycle
rograms. These programs are the delivery mechanisms for the architecture and the actual acilities and systems that house and automate the services that comprise the capability. Figure 1 also shows the Architecture Repository as the warehouse of all information about all apabilities regardless of which program is producing the architecture information.


Using the Architecture The NEA and NEAF provide many benefits to the City. Architecture can be used to analyze the risks, benefits and alternatives more rigorously when planning transformations of current activities or future development. Used as a planning and investment management tool, architecture rationalizes the use of limited resources and by more thorough and coordinated planning, it frees up money for new projects. Therefore an investment in architecture pays dividends in cost savings, and by increasing efficiency and effectiveness, it enables City government to do more with less.

The Mayor benefits by seeing that the portfolio of capabilities associated with each Line of Business is aligned with mayoral goals and objectives. The Mayor also benefits by having a single source of information about the health of NYC Business Operations and the cost of the capabilities and the enterprise.

Deputy Mayors benefit by having a complete inventory of the policies, people, processes, systems, tools, and facilities that are driving cost in the Line of Business for which they are responsible. The architecture provides an understanding of planned, budgeted, and actual dollars being spent and the distribution of that money across the portfolio of capabilities and the agencies that are delivering them.

Agencies benefit by using architecture to increase the usefulness and success of their programs, and ensure their alignment with City missions. Architecture can reduce redundancies of effort and expense, and maximize the use of existing resources. It can clarify the mechanisms for achieving agency goals and objectives, or make plain any better alternatives. It can improve the management of investments, suppliers, risk, contracts, and business maturity.

To obtain these benefits, however, the first step is to begin architecting. The Enterprise Architecture Program (EAP) owned by DoITT is assisting this effort to begin architecting by developing a Citywide Architecture Capability (CAC) and offering it for the agencies to leverage. The CAC includes a Citywide architecture tool environment that facilitates the creation of the very blueprints the NEAF calls for. This environment, the people doing the architecture work, and the architecture training will be available as a service offering to the City at large. Agencies will benefit from not having to make a duplicate investment in their own architecture tool environments.

For the NEA to become an effective tool, it must be built from the architecture created, collected, and deposited in the Architecture Repository. NEAF-compliant architecture information should be a requirement in any solicitations for projects involving new capabilities or substantive changes to current capabilities.


FRAMEWORK A framework is a specification and set of standards for architecting business capabilities. To understand the NEAF, it is important to look at the other frameworks upon which it is based: the Zachman Framework for Enterprise Architecture, the Department of Defense Architecture Framework (DoDAF), and the Federal Enterprise Architecture Framework (FEAF).

Zachman Framework John Zachman published an article in 1987 that presented a blueprint for change management in business, known as the Zachman Framework, which has since become an industry-standard.8 According to Zachman, the architecture for an enterprise’s systems should support the enterprise’s business objectives. From that architecture, the strategic plan of the enterprise can be understood.

Zachman uses the construction analogy to define the components of the enterprise: systems, like buildings, require blueprints. The first step in applying the Zachman Framework is to understand the analysis approach. For each business system or capability, the what, how, where, who, when, and why are analyzed from the perspectives of the planner, owner, designer, builder, and subcontractor. The Zachman Framework can be shown as a table with six columns and five rows, where each cell in the table contains information that describes the enterprise.

What How Where Who When Why

Planner

Owner

Designer

Builder

Subcontractor

Table 1. Basic Zachman Framework

Table 1 shows the simple framework structure. The information specified in each cell is designed to facilitate informed decision-making. To understand what information is gathered when architecting a capability, the following question is asked:

What decisions are the planner, owner, designer, builder and subcontractor making and what information do they need to make these decisions?

Each row represents a different perspective of the capability. Progressing from the top row to the bottom, the perspective becomes narrower and the information becomes more detailed. Each cell in the Zachman Framework contains information representing a different aspect of the capability.

8 A Framework for Information Systems Architecture (John A. Zachman, IBM Systems Journal, Vol. 26, No. 3, 1987)


As an example, for the planner, “why” is policy; for the owner, “why” is goals and objectives; and for the design engineer, “why” is requirements.

Department of Defense Architecture Framework (DoDAF)

The Department of Defense Architecture Framework (DoDAF) defines a common approach for architecting capabilities for both military and business operations. 9

DoDAF specifies four sets of architecture diagrams describing the capabilities of an enterprise and its underlying systems:

The Overview architecture diagrams (known All View or AV architecture diagrams) describe the scope and context of the business capability being architected.

The Operational architecture diagrams (known as Operational View or OV architecture diagrams) describe what needs to be done and who does it.

The Systems architecture diagrams (known as Systems View or SV architecture diagrams) describe what resources are used to accomplish what is described in the OV architecture diagrams.

The Technical Standards architecture diagrams (known as Technical Standards View or TV architecture diagrams) describe the diagram and protocol standards and business guidelines that drive the OV and SV architecture diagrams.

The NEA is described using about two dozen architecture diagrams, which are presented in the next section. These diagrams are the metaphorical painting canvases on which the picture of the enterprise is created by gathering the information required by the planner, owner, and design engineer. In each cell of the NEAF specific diagrams are created. .

Federal Enterprise Architecture Framework (FEAF)The Federal Enterprise Architecture Framework (FEAF) is a specification for the construction of five interrelated reference models designed to facilitate cross-agency analysis and the identification of duplicative investments, gaps, and opportunities for collaboration within and across Federal Agencies.

As the owners of the FEAF and the Federal Enterprise Architecture (FEA), the Office of Management and Budget (OMB) built the following reference models:

The Performance Reference Model (PRM) as a standardized framework to measure the performance of major IT investments and their contribution to program performance. These measurements are used by agencies to better manage the business of government at a strategic level, by providing a means for using an agency’s EA to measure the success of IT investments and their impact on strategic outcomes.10

The Business Reference Model (BRM) is a function-driven framework for describing business operations of the Federal government independent of the agencies that perform them. It presents a functional (rather than organizational) view of the Federal government’s Lines of Business, including its internal operations and its services for citizens, independent of the agencies, bureaus, and offices performing them.11

The Service Component Reference Model (SRM) is a business and performance driven functional framework that classifies service components with respect to how they support the business. It

9 Department of Defense Architecture Framework, Version 1.0, Volume 1: Definitions and Guidelines 10 FEA Consolidated Reference Model Document, Version 2.3, October 2007 11 FEA Consolidated Reference Model Document, Version 2.3, October 2007


identifies and classifies horizontal and vertical service components supporting Federal agencies and their IT investments and assets. The SRM is organized across horizontal service areas, independent of business functions, providing a foundation that can be leveraged for reuse of applications, application capabilities, components, and business services.12

The Technical Reference Model (TRM) is a component-driven, technical framework used to identify the standards, specifications, and technologies that support and enable the delivery of service components and capabilities. It provides a foundation to advance the reuse and standardization of technology and service components from a government-wide perspective. Aligning agency capital investments to the TRM leverages a common, standardized vocabulary, allowing interagency discovery, collaboration, and interoperability. Agencies benefit from economies of scale by identifying and reusing the best solutions and technologies to support their business functions, mission, and target architecture.13

The Data Reference Model (DRM) is a model describing, at an aggregate level, the data and information that support program and business line operations. Using a flexible and standards-based framework enables information sharing and reuse across the Federal government via the standard description and discovery of common data and the promotion of uniform data management practices. The DRM provides a standard means by which data may be described, categorized, and shared.14

For more information, see the Federal Enterprise Architecture website:

http://www.whitehouse.gov/omb/egov/a-2-EAModelsNEW2.html

12 FEA Consolidated Reference Model Document, Version 2.3, October 2007 13 FEA Consolidated Reference Model Document, Version 2.3, October 2007 14 FEA Consolidated Reference Model Document, Version 2.3, October 2007


The NEA Framework (NEAF) The NEA Framework is built from elements of the three foundational frameworks described above. From the Zachman Framework the NEAF takes the matrix of views; from the DoDAF, the diagrams; and from the FEAF, the reference models. Industry-standard methods for creating diagrams are applied to these structural foundations for the NEAF. These modeling methods are taken from the Unified Modeling Language (UML), the Integrated Definition (IDEF) family of languages, Activity-Based Costing (ABC), Business Process Modeling Notation (BPMN), and the methods of the Department of Defense Architecture Framework (DoDAF). These methods are described in a following section.

What We Took From Zachman To build the NEA and the NEAF, the EAP took the matrix from the Zachman Framework because that is all that was needed. The matrix works like the game show Hollywood Squares. In each cell are placed questions that need to be answered. We then specify what information needs to go into the architecture and be accessible via that cell in order to answer the questions.

The NEAF uses only the first three rows of the Zachman Framework. Capabilities being architected have a planner, owner, and design engineer’s view.

In architecting a capability, we first establish a planner’s view. The list of information required in a planner’s view of a capability is that information required by a City planner to decide whether the capability should be part of the strategic plan. If the capability is put into the strategic plan, then it is assigned a start date. When the start date arrives, the architect gathers and records the information required for the owner’s view of the capability.

Table 2. Matrix information in Zachman Framework


What We Took From the DoDAF Put simply, we took diagrams. We use the diagrams to organize and depict the information we gather to answer the questions in the Hollywood Squares. The Zachman Framework provides the structure to house DoDAF architecture diagrams. It was necessary to create additional diagrams because the DoDAF is incomplete.

For each capability in NYC’s Strategic IT Plan (PlanIT), the NEA will contain some combination of the following architecture diagrams. The distribution of these diagrams in the cells of the Zachman Framework is shown in Table 3.

A. Overview Diagrams 1. Capability Overview (AV-1) 2. Dictionary of Terms (AV-2) 3. Capability Maturity Model (AV-3) 4. Business case (AV-4) 5. Capability Scenarios / Uses (AV-5)

B. Operational Diagrams 1. Operational Concept /

Vision (OV-1) 2. Operational

Communities/Trading Partners (OV-2)

3. Capability and Service Taxonomy (OV-3a)

4. Service to Process Mapping (OV-3b)

5. Organizational Structure (OV-4a)

6. Organizational Staffing (OV-4b)

7. Process Taxonomy (OV-5a)

8. Process Performance/Context (OV-5b)

9. Process Information Flow (OV-5c)

10. Business Rules (OV-6a) 11. Process Details (OV-6c) 12. Capability and Services

Training (OV-6d) 13. Data (OV-7a)

Table 3. Diagrams in Zachman Framework 14. Data State (OV-7b) 15. XML Representation of

Data (OV-7c)

C. Systems Diagrams

1. System Interface Description (SV-1) 2. System Communications Description (SV-2) 3. Application Portfolio Performance (SV-5) 4. System Evolution Description (SV-8) 5. Sequence Diagram (SV-10c)


D. Technical/Technology Diagrams

1. Technical Standards Profile (TV-1) 2. Technical Standards Forecast (TV-2)

These diagrams are associated with capabilities, except when they are used in the Mayor’s view of NYC business operations (BOP), which is organized by the reference models discussed below. Table 3 shows the diagrams that might be found for capabilities that are Agency-specific, Deputy Mayor/Line of Business-specific, and Citywide.

What We Took From the FEAF All we took from the FEAF were the Reference Model names and their underlying concepts. In the Mayor’s view of the City, we collectively refer to certain BOP diagrams using the Reference Model names. Here is the mapping:

A. Business Reference Model 1. Overview Diagram having background information (AV-1) 2. Dictionary as a source of capability specific terms (AV-2) 3. Process Taxonomy / Activity Model (OV-5a) 4. Vision and Concept of Operations Model (OV-1) 5. User Group and Dependencies (OV-2)

B. Performance Reference Model 1. Maturity Model describing goals and objectives (AV-3) 2. Business Polices and Rules (OV-6a)

C. Service Reference Model 1. Capability and Service Taxonomy (OV-3a) 2. Service to Process Mapping (OV-3b) 3. Organizational Structure (OV-4a) 4. Community Information Exchange Requirements (OV-2)

D. Data Reference Model 1. Data Domains and Business Objects (OV-7a)

E. Technical Reference Model 1. System and Interface Descriptions (SV-1) 2. Network Description (SV-2) 3. Product and Standards Inventory (TV-1) 4. Product and Standards Forecast (TV-2)

What the NEAF-Based Architecture Looks Like At the very top of the architecture we have a set of BOP diagrams that describe City business operations from a Mayor’s point of view and divide the enterprise into Lines of Business or zones. Below that we have the portfolio of Citywide, Line of Business, and Agency capabilities.

A. NYC Business Operations — A Mayor’s View NYC BOP (AV-1) Overview and Background

NYC BOP (AV-2) Dictionary

NYC BOP (OV-1) Vision for NYC Business Operations

NYC BOP (OV-2) Line of Business Dependencies and Information Exchange Requirements


NYC BOP (OV-5a) Citywide Process Taxonomy

NYC BOP (AV-3) Citywide Goals, Objectives, and Maturity Model

NYC BOP (OV-3a) Capability and Service Taxonomy

NYC BOP (OV-3b) Service to Process Mapping

NYC BOP (OV-4) Organization Structure and Capability Coverage

NYC BOP (OV-6a) Citywide Policy and Business Rules

NYC BOP (OV-7a) Data and Authoritative Sources

NYC BOP (SV-1) Citywide Service Delivery Centers

NYC BOP (SV-2) Citywide Network

NYC BOP (TV-1) Citywide Technology Inventory

NYC BOP (TV-2) Citywide Technology Forecast

B. Citywide Capabilities Citywide Architecture Capability (CAC)

Citywide Collaboration Capability (CCC)

Citywide Identity Management (IDM)

Shared Services Center and Service Management Capability (DCC)

Citywide Network Capability(CNC)

Emergency Communications Capability (ECC)

Emergency Public Notification Capability (EPC)

First Responder Network (FRN)

C. Lines Of Business-Specific Capabilities Health and Human Services (HHS)

Public Safety (PS)

Economic Development (ED)

Foundational IT (FIT)

D. Agency-Specific Capabilities Department of Finance

Department of Small Business Services

NYPD

FDNY

In summary, programs use the NEA Framework to build the NEA. The NEA Program (NEAP), owned and operated by DoITT, facilitates the construction of the Mayor’s View. Figure 12 shows one program lifecycle as an example. The program is responsible for the architecture, delivery, and operations of the capability and the underlying services, policies, organizations, people, processes, facilities, training, and systems. It may be only one of many programs that deliver the services of one capability. Throughout the program lifecycle, questions are asked and information is produced. This architecture information is collected and stored in the Architecture Repository. This is an ongoing iterative process that is executed until all the information required to answer the questions posed by Raines’ Rules and the information required to cost the capability and show a positive business case have been gathered and recorded in the NEA.



Figure 12. A program in the program lifecycle and executing the program management process

ARCHITECTURE DIAGRAMS Architecture diagrams, also known as blueprints, are those graphical, textual, and tabular items that are developed in the course of architecting a capability. Diagrams describe the characteristics of a capability and the purpose of each diagram for the people that will use it.15 Diagrams are also used to establish the Mayor’s view of the City. The Mayor’s view, whose purpose is to zone the enterprise and establish the ordinances for architecting capabilities, is comprised of reference models comprised of diagrams.

The framework for the federated Citywide Enterprise Architecture includes the FEAF Reference Models and a subset of the DoDAF architecture. The diagrams are designed to facilitate costing. Since our intent is to use blueprints for costing and capability evaluation, we have created other architecture diagrams that were missing from the DoDAF but help in these respects. A list of diagrams used to describe a capability follows.16

The Diagram as a Painting Canvas A diagram is the architect’s means of recording and portraying basic information about the capability. Since the NEAF is a set of standards for architecting capabilities, it also specifies standards for the diagrams. The specification for how diagrams are laid out begins with title blocks that frame the diagram and painting area. The standard diagram has the following blocks: a mandatory diagram description area, the logo of the City (NYC), an optional description block, and the painting area.

All diagrams have the same title blocks. Some diagrams describe existing conditions and others describe proposed conditions for capabilities that do not yet exist. The diagrams that document existing conditions are called “as-is” diagrams. Those that describe proposed conditions are the “to-be” diagrams. One special diagram, which is described in more detail later, is the System Evolution Description diagram, which documents the transition from the “as-is” to the “to-be.” This diagram is also referred to as a transition plan.

The Paint The architect paints on the canvas with architecture artifacts. The artifacts are laid down on the diagrams and the choice of artifacts depends on the diagram. The following sections describe each diagram and the artifacts that can be placed on each one, with a focus on the purpose of the diagram and artifacts. The complete list of artifacts follows.

The Artifacts This list shows some of the artifacts that the architect lays down on the diagrams. These types of artifacts differentiate architectural information from the information in operational data stores.

1. Finding 2. Goal 3. Objective 4. Strategy 5. Architecture 6. Maturity Level 7. Leading Practice

15 DoDAF, Volume I, 5 16 adapted from Defense Business Transformation Agency homepage, http://www.defenselink.mil/DBT/products/2007_BEA_ETP/bea_4_1.html


8. Material Weakness 9. Requirement 10. User Group or Community 11. Location 12. Need Line or Dependency (between user groups) 13. Information Exchange Requirement (between user groups) 14. Capability 15. Service 16. Organizational Unit 17. Policy 18. Business Rule 19. Operational Activity or Process 20. Task 21. Method 22. Role (represented using swim lanes, which are visual elements that depict who or what is working

on particular subsets of processes, and collections of roles called pools) 23. Data Class 24. Business Object 25. Data Object (work product and deliverable) 26. Input 27. Output 28. Training Course 29. Business Event 30. System Node, Entity, Component, and Element 31. Application 32. Product 33. Standard

The Diagrams

Overview Diagrams Some general aspects of a business capability are captured in the Overview architecture diagrams. The Overview architecture diagrams provide basic background and identifying information about the capability as well as findings and recommendations. The Overview architecture diagrams are described below.

Capability Overview The Capability Overview diagram is an executive-level summary of the capability with an emphasis on definition and purpose. The Capability Overview is presented as text and generally comprises the following details:17

Identifying information such as who is the owner, who is the architect, and who are the participating engineers

Background and drivers

Definition

Purpose and viewpoint

17 DoDAF, Volume II, 3.1.1


Context

Tools and file format used

Findings

Dictionary The Dictionary diagram, presented as text, defines terms relevant to the capability.18 The Dictionary provides a central source for all definitions including those that may be provided for convenience within another product as well. The Dictionary is one of the most important diagrams, as it provides an unambiguous set of terms that provide a foundation for all discussion about the capability. At a minimum, the Dictionary is a glossary with definitions of terms used in the given capability description.19

In the Dictionary one lays down architecture artifacts called terms, just like in a traditional dictionary. The terms are created for all concepts that are not defined elsewhere in the architecture of the capability. The Dictionary of complete concepts and terms is generated by collecting all the concepts, whether explicitly created as terms in the dictionary diagram or sourced from other diagrams. Other artifacts that contribute to the complete Dictionary include:

User Communities found in Operational Node Connectivity diagrams

Business Objects such as invoices and contracts, found in the Data Models, and more complex Data Objects such as the Project Approval Form (PAF) found in the Process Models

Business Activities such as cost accounting found in the Activity Models.

Maturity Model The Capability Maturity Model diagram records the goals and objectives for the capability. It specifies that through a strategy and release of the architecture, goals and objectives are met, and it shows how a capability maturity level is achieved. This diagram can also indicate whether a particular release of the architecture addresses material weaknesses and best practices.

In recording goals, objectives, strategies, and maturity levels in the architecture and associating all other business and system artifacts with these goals, one uses the architecture to ensure that all policies, organizations, training, processes, systems, technology enablers, governance structures, staffing, and facilities are aligned with goals and objectives.

By recording startup and operational cost information associated with certain architecture artifacts, one uses the architecture also to determine how much it costs to achieve a particular goal or objective. The architecture becomes a mechanism to cost capabilities and to evaluate supplier proposals.

Business Case The Business Case diagram defines how the resources and business processes support the business. The business case for a capability is determined using the cost information stored in the architecture. It is computed by adding up all the benefits that can be articulated in a dollar amount and subtracting the total development and maintenance/support costs. Therefore the architecture must enable the architect and engineers to record all development/startup and maintenance costs.

18 DoDAF, Volume II, 3.2.1 19 A Practical Guide to Federal Enterprise Architecture (Chief Information Officer Council, Version 1.0, February 2001)


Requirements Requirements define the functional and technical or non-functional needs of the capability. The Requirements diagram enables the architect to record requirements hierarchically and to associate the requirements with the services of the capability. The capability taxonomy and the decomposition of the capability into services are created in the Capability Taxonomy diagram.

Requirements can also be recorded as use cases both graphically and textually. A complete description of what a use case is and how to create one is found in documentation provided by the standards bodies that own the Unified Modeling Language (UML) used to create use cases and scenarios.

Architecting a capability must start with the “why” described in the policies, goals, objectives, and requirements. Ultimately the requirements are used to evaluate supplier proposals and products or applications being acquired.

Operational Diagrams The Operational diagrams focuses on the operational or business aspects of the capability. They describe the vision for the capability as well as policies, business rules, activities or processes, roles, tasks, procedures, methods, training, organization structures, staffing, and business events as triggers and as outcomes of processes.

Operational Concept and Vision The Operational Concept and Vision diagram provides a leadership position and highlights key concepts and differentiators or interesting or unique aspects of the capability that make it different from how business is currently being conducted. The Operational Concept and Vision provides a quick, high-level description of what the capability is supposed to do and how it is supposed to do it. It consists of a graphical executive summary with accompanying text. It should convey, in simple terms, what the capability is about and an idea of the players and operations involved.20 The Operational Concept and Vision diagram is often displayed as an artist’s rendering or, in some cases, a short video.

The NYC Operational Concept and Vision diagram is a one-page graphical portrayal of how NYC business operations are aligned with the three mayoral goals of accessibility, transparency, and accountability. This is an example of a concept of operations (CONOPS) diagram, which is based on the Porter Value Chain 21 business model, which defines a value chain as a series of variable delivery pipes between customers and suppliers. The operation of the pipes is transparent to the customers.

The Porter Value Chain is a strategic concept used to analyze the activities required to operate an enterprise successfully. The value chain comprises five primary generic activities (inbound logistics, operations, out bound logistics, marketing and sales, and service) and four industry-specific support activities (procurement, technology development, human resource management, and firm infrastructure). The Porter Value Chain starts with a process view of the enterprise, in which the enterprise is a system made up of subsystems. Each subsystem has inputs, transformation processes, and outputs. Every input, transformation process, and output requires the acquisition and consumption of resources. The effectiveness and efficiency of this acquisition and consumption are reflected in the value of the enterprise.

20 DoDAF, Volume II, 4.1.1 21 Michael Porter, Competitive Advantage: Creating and Sustaining Superior Performance (1985)


Operational Node/User Group Connectivity The Operational Node/User Group Connectivity diagram is a key component of the Operational diagrams that records user groups or user communities and the information exchange requirements (IER) between them.

The diagram graphically depicts the user groups with need lines (dependencies) between those groups that indicate a need to exchange information. Associated with these need lines are actual information-exchange requirements that need to be addressed by actual information exchanges between operational activities recorded in the activity model. The graphic includes internal operational nodes (internal to the capability) as well as external parties. This architecture product is intended to track the need to exchange information between groups.22

The DoDAF provides the standard methods for developing this diagram.

Once the City has established an experience base with Information Exchange Requirements and the cost for implementing them, the Information Exchange Requirements can be considered in costing a capability.

Capability and Service Taxonomy The Capability and Service Taxonomy diagram records how the capability is broken down into services. Depending on the granularity or size of the capability, the taxonomy might decompose the capability into smaller capabilities before getting down to the service level where each service is described as a collection of processes, people, and tools. This use of the term “service” in these operational diagrams is differentiated from the use of the term in Web services, which are interfaces to components of applications that automate steps within a process. Web services are components modeled in a Systems Interface Description diagram.

A key step here is to map all the requirements previously gathered to Services to ensure that a sufficient number of the requirements are addressed by the capability and service taxonomy as constructed.

Service-to-Process Mapping A service is a set of processes, the accompanying people, roles, and tools used to facilitate the process. Before we can map services to processes, we must first create a Process Taxonomy diagram, which is described later. Once we have the process taxonomy, the Service-to-Process Mapping diagram is created as a matrix or spreadsheet.

Having this mapping ensures the business that it knows what processes and accompanying resources are required to deliver the services. The delivery of services requires

1. Doctrine or policy and business rules, which are recorded in the OV-6a diagram 2. Organization structure, roles, and staffing, which are recorded in the OV-4a and OV-4b diagrams 3. Training, recorded in the OV-6d diagram 4. Materiel in the form of processes and data, recorded in the OV-6c and OV-7 family of diagrams 5. Leadership 6. Personnel 7. Facilities

The recording and description of services in the Service-to-Process Mapping diagram serve as the segue to the world of engineering and design where we list what people traditionally think of as architecture: systems and applications.

22 DoDAF, Volume II, 4.2.1


Organizational Structure The Organizational Structure diagram is similar to an organization chart. It illustrates the structure or relationships among the organizational units that are the key players in delivering and operating the capability. This diagram clarifies the various relationships that exist between organizations and sub-organizations, and between internal and external organizations.23 Once the organizational units and the relationships between them are established, services are mapped to the organizational units that deliver them. This mapping ensures that service offerings are covered organizationally or identifies gaps.

Organizational Staffing In addition to mapping services to organizations, we map roles required for delivery of services to organizations. This is a prerequisite to staffing. While the organizational relationships are recorded in the Organizational Structure diagram, the staffing of the organizations is recorded in the Organizational Staffing diagram. The staffing model is a matrix of organizational units to roles. In the intersecting cells we record the number of people required. This is necessary for costing. In the architecture we record expected costs for roles. Then knowing how many people are needed in each role, we can cost the delivery of a service in terms of roles as staffed.

Knowing the roles and staffing in the current business landscape (“as-is”) and the proposed capability (“to-be”) enables the architect to determine the fit, gaps, costs, and benefits to the business.

Process Taxonomy The Process Taxonomy diagram describes the operations that are normally conducted in the course of achieving a mission or a business goal.24 This architecture diagram describes the processes in a hierarchical manner. These processes are descriptions about what the business does to provide a service, and the process detail diagrams (Process Taxonomy diagram, Process Context and Performance diagram, and Process Information Flow diagram) describe how these processes are performed. The “how” is described in term of activities, tasks, methods, roles, triggers, outcomes, and data. The IDEF family of methods is used to develop the Process Taxonomy diagram and the other process detail diagrams.

Process Context and Performance The Process Context and Performance diagram provides the architect and the owner with an understanding of the scope, context, and performance of each process in the taxonomy. For each process or activity of the process taxonomy, we describe the scope and context in the form of inputs and outputs, the policies that constrain or govern the operation of the process, the systems used to automate the process, and the roles and skills required to execute the process. The diagram can also record the training requirements.

Information about the process performance is collected by tallying the cost of the systems, roles, and training. Information about performance improvements is collected through the application of business rules associated with the processes and by training people performing the process. The costs are depicted as pie charts.

Performance enhancements are also realized by defining and standardizing the inputs and outputs of the process. For example, a capability needs awareness of its process partners and their outputs to achieve a maturity level of 4 as defined by Carnegie Mellon University's Software

23 DoDAF, Volume II, 4.4.1 24 DoDAF, Volume II, 4.5.1


Engineering Institute (SEI).25 If the processes being designed are dependent on processes outside the scope of this capability, then the data being transferred between the processes must be well-defined and agreed to. Well-defined means that a UML or IDEF1X-based data model exists, and that the process partners agree to the semantics and schema.

Process Information Flow The Process Information Flow diagram describes the processes at level 1 of the Process Taxonomy diagram and shows the information flow between them. With the OV-5 family of diagrams, we are building up an understanding of the processes that are associated with the services in the capability.

The idea here is to understand where data is coming from and where it is going to, and to demonstrate to the customer that all the information needed to run the capability has a purpose, source, and consumer.

Business Rules Business rules are constraints on an enterprise and the activities performed by the enterprise. These rules also apply to the information produced or consumed in daily operation. These rules can include such guidance as the conditions under which operational control passes from one entity to another or the conditions under which a human role is authorized to proceed with a specific activity.26

While business rules are textual in nature, they also appear graphically in the Process Details diagram to show unambiguously what tasks they constrain or govern.

If the business rule is related to content or data and its structure, then it will also appear in the data models attached to the data entity or class to which it applies. If the rule applies to process, then it is intended to make the handling of the process unambiguous. In this case the rule is attached to the process steps that it governs.

Special business rules that are process related are referred to as internal controls. They too are attached to the process steps they govern. Internal controls ensure that processing is unbiased. For example, financial management processes have numerous internal controls used by auditors to ensure the proper handling of financial information.

Process Details The Process Details diagram, also known as a process model, provides a time-ordered examination of the information exchanges between participating operational nodes as a result of a particular scenario. This architecture diagram also describes the dynamic behavior of business processes or a mission or operational thread.27 It does this by recording business events as triggers and outcomes of the process and the steps performed to get the business from trigger to outcome. It also records the reason business objects change state and the information exchanged when a business event occurs.

While the Process Information Flow diagram states that information flows, the Process Details diagram states when it flows and why, and provides relevant details.

25 Carnegie Mellon Software Engineering Institute, Capability Maturity Model Integration (CMMI) Web Site, http://www.sei.cmu.edu/cmmi/ 26 DoDAF, Volume II, 4.6.3 27 DoDAF, Volume II, 4.6.11


The process models bring together much of the information gathered in other architecture diagrams for a comprehensive view of how activities are performed. They use the Business Process Modeling Notation (BPMN) to show the following elements:

Communities as collections of roles. These communities are called pools.

Roles as swim lanes in the pool

Business rules as constraints on tasks

Data (or business objects) associated with business events

Business events as triggers and outcomes of process steps.

A sequenced set of tasks that get one from trigger to outcome.

Capability and Services Training The Capability and Services Training diagram describes the courses that are required. Each service in the Capability Service Taxonomy is diagrammed with required courses listed. This diagram also enables the architect to specify which roles require training. With this diagram, the architect can also inventory personnel assigned to existing roles and establish a record of who has been trained. This is a key element of a gap assessment. It is also key to estimating the cost of establishing a capability.

Data Model The Data Model diagram describes data domains, and within domains it describes the business objects or entities and associated attributes. For each attribute the architect or engineer can specify data type, length, and whether the field is required. At the domain level an authoritative source is assigned in the form of an agency. Having a record of authoritative sources and data stewards is extremely important when arbitrating data quality issues and standards.

In the NEAF we can apply either the UML or the IDEF1X methods for modeling data. The UML method is typically referred to as an object modeling method and the IDEF1X is a relationship modeling method.

Data State For each class of data in the Data Model diagram, Data State diagrams can be created that document the valid state changes that a particular class of data might go through. We use the UML for modeling state and ensure that all business events that trigger changes in state are also in the process models as triggers of work or as outcomes.

Data states and the business events that trigger changes of state are the primary concern of a Situational Awareness System because it is the business events that define a situation that someone might be interested in knowing about. The system must know about the events, the information tied to the events, and the interested parties.

XML Representation of Data The XML Representation of Data diagram presents the information in the Data Model and Data State diagrams using the Extensible Markup Language. We do this to establish XML-based data exchange standards between trading partners.

Systems Architecture Diagrams The Systems Architecture diagrams are a set of graphical, textual, and tabular products that describe systems and interconnections providing for, or supporting, enterprise functions. The Systems Architecture diagrams associate systems resources to the operational resources. These


systems resources support the operational activities and facilitate the exchange of information among operational nodes.28

System Interface Description The System Interface Description diagram depicts system nodes and the systems resident at these nodes to support the organizations or human roles represented by the operational nodes of the Operational Nodes/User Groups diagram. This diagram also identifies the interfaces between systems and system nodes. It can be used to identify system nodes and systems that support operational nodes. The diagram links the Operational and Systems Architecture views by depicting the assignments of systems and system nodes (and their associated interfaces) to the operational nodes (and their associated need lines) described in the Operational Nodes/User Groups diagram.29

The inventory of systems and system interfaces is required for costing. Cost information recorded for each system and/or interface is the standup/installation cost and the monthly operations/support costs.

System Communications Description The System Communications Description diagram depicts information about physical locations, communications systems, communications links, and communications networks. While the System Interface Description diagram depicts interfaces between systems or system nodes, the System Communications Description contains a detailed description of how each interface is implemented.30

Application Portfolio Performance The Application Portfolio Performance diagram is a mapping of applications to the operational activities or processes they automate. The simple mapping of applications to processes is valuable because it tells us which applications are being employed in the automation of business processes, which are operational aspects of the business. Applications that are not associated with mission critical business processes are treated with the appropriate sense of priority.

The performance of the portfolio is established by categorizing applications using two indicators: strategic and mission critical. This results in four categories:

1. Strategic and Mission Critical (Gold) 2. Not Strategic and Mission Critical (Bronze) 3. Strategic and not Mission Critical (Silver) 4. Not Strategic and not Mission Critical (Blue) or legacy.

Looking at the number of applications in each category relative to the total number of applications in the portfolio provides a view of the performance of the portfolio. For example, if the number of legacy systems is greater than the number of systems that are both strategic and mission critical (gold), then performance is low and action must be taken to reduce the number of legacies.

System Evolution Description The System Evolution Description diagram captures how the capability, services, and the underlying systems will evolve over time. The description of the evolution is graphically depicted

28 DoDAF, Volume II, 2.1.2 29 DoDAF, Volume II, 5.1.1 30 DoDAF, Volume II, 5.2.1


as a timeline with milestones. To the milestones we attach physical systems that need to be built, applications that need to be installed, organizations that need to be built, findings that need to be addressed, and policies that need to be established.

Sequence The Sequence diagram provides a time-ordered examination of the data exchanged between participating external and internal systems, system functions, or human roles as a result of a particular scenario. The Sequence diagram may reflect system-specific aspects or refinements of critical sequences of events described in the Operational architecture diagrams.31

Sequence diagrams are a key product used both in the construction of systems and in supporting the people using the systems. For example, if a service call is placed, the service desk can use the Sequence diagrams for problem determination. The Sequence diagrams help the service desk narrow the scope of the problem and the systems involved.

Technical Standards Architecture Diagrams The Technical Standards Architecture diagrams are the products and protocols used to implement components of the architecture and the interfaces between the components.

Technical Standards Profile The Technical Standards Profile diagram is a collection or inventory of product standards that are relevant to the capability being architected. 32 The Technical Standards Profile diagram is the list of products and protocol standards with names and descriptions. Since this is a simple list, one can use a spreadsheet to gather and depict the information, but the list of products and standards needs to be imported into the NEA Architecture Repository.

Technical Standards Forecast The Technical Standards Forecast diagram contains expected changes in the technology-related standards and conventions that are documented in the Technical Standards Profile diagram.33 The Technical Standards Forecast diagram is presented as text in a table.

31 DoDAF, Volume II, 5.10.11 32 DoDAF, Volume II, 6.1.1 33 DoDAF, Volume II, 6.2.1


METHODS This section defines the industry-standard methods that the City will apply in developing business-process models, activity models, data models, and other architecture diagrams. Five standards exist to provide guidelines for creating these diagrams and their accompanying text:

Unified Modeling Language™ (UML®)34

Integrated Definition Languages (IDEF)35

Activity-Based Costing36

Business Process Modeling Notation (BPMN)37.

Department of Defense Architecture methods.

Unified Modeling Language (UML) Unified Modeling Language (UML) is a standard method to specify, visualize, and document models38 of software systems and, by extension, business processes and architectures.

UML 2.0 defines thirteen types of diagrams, divided into three categories. Six diagram types represent static application structures, three represent general types of behavior, and four represent different aspects of interactions:

Structure Diagrams comprise the Class Diagram, Object Diagram, Component Diagram, Composite Structure Diagram, Package Diagram, and Deployment Diagram.

Behavior Diagrams comprise the Use Case Diagram (used by some methodologies during requirements gathering), Activity Diagram, and State Machine Diagram.

Interaction Diagrams, all derived from the more general Behavior Diagram, comprise the Sequence Diagram, Communication Diagram, Timing Diagram, and Interaction Overview Diagram.39

Note that we will use only the Class Diagram and Sequence Diagram in constructing our architecture. Note also that some DoDAF architecture products, such as AV-1, do not have a UML product equivalent.

Integrated Definition (IDEF) Family The family of Integrated Definition (IDEF) languages is a set of over a dozen modeling methods. The development of this set of methods was an initiative managed by the United States Air Force to integrate computers and manufacturing. Two methods are of particular interest in developing Enterprise Architecture: IDEF0 and IDEF1X.

The IDEF0 method was designed to model the decisions, actions, and activities of an organization or system. The IDEF0 method was derived from a well-established graphical language, the Structured Analysis and Design Technique (SADT). The United States Air Force commissioned the developers of SADT to develop a function-modeling method for analyzing and

34 http://www.omg.org/docs/formal/05-04-01.pdf 35 http://www.idef.com/ 36 Kaplan, Robert S. and Bruns, W. Accounting and Management: A Field Study Perspective (Harvard Business School Press, 1987) ISBN 0-87584-186-4 37 http://www.bpmn.org/ 38 Introduction to OMG's Unified Modeling Language (UML) 39 Introduction to OMG's Unified Modeling Language (UML)


communicating the functional perspective of a system. Effective IDEF0 models help to organize the analysis of a system and to promote good communication between the analyst and the customer. IDEF0 is useful in establishing the scope of an analysis, especially for a functional analysis. As a communication tool, IDEF0 enhances domain expert involvement and consensus decision-making through simplified graphical devices. As an analysis tool, IDEF0 assists the modeler in identifying what functions are performed, what is needed to perform those functions, what the current system does right, and what the current system does wrong. Thus, IDEF0 models are often created as one of the first tasks of a system-development effort.40

IDEF1X is a method for designing relational databases with a syntax designed to support the semantic constructs necessary in developing a conceptual schema. A conceptual schema is a single integrated definition of the enterprise data that is unbiased toward any single application and independent of its access and physical storage. Because it is a design method, IDEF1X is not particularly suited to serve as an “as-is” analysis tool, although it is often used in that capacity as an alternative to IDEF1. IDEF1X is most useful for logical database design after the information requirements are known and the decision to implement a relational database has been made. Hence, the IDEF1X system perspective is focused on the actual data elements in a relational database. If the target system is not a relational system (for example, an object-oriented system), IDEF1X is not the best method. 41

Activity-Based Costing (ABC) Activity-Based Costing (ABC)42 was developed in the manufacturing sector and its principles were formalized by the Consortium for Advanced Manufacturing-International.43 ABC is a costing model that identifies activities in an organization and assigns the cost of each activity resource to products or services according to actual use by each. The IDEF methods are used for modeling activities. Using boxes representing activities and cost factors being considered right now, we have a rudimentary costing model.

Traditional cost accounting arbitrarily adds a broad percentage of expenses onto direct costs to allow for indirect costs. Instead of using imprecise estimated percentages to allocate costs, ABC identifies cause-and-effect relationships to assign costs objectively. Once costs of activities have been identified, the cost of each activity is attributed to each product or service to the extent that it uses the activity. In this way, ABC identifies areas of high overhead costs per unit and directs attention to finding ways to reduce those costs.

ABC is therefore a tool for planning and control. As a method for understanding resource costs assigned through activities to associated products and services, ABC is used to support strategic decisions such as pricing, outsourcing, and identification and measurement of process improvement initiatives. ABC is necessary for value chain analysis, which looks at every step of business operations to deliver maximum value for the least possible total cost. By generating the actual costs of products and services, ABC allows competitive options to be more accurately compared when planning investments in new or changing projects. This is the formalized AoA of the program life cycle discussed above in Figure 9 in the section: Building the NEA.

40 http://www.idef.com/idef0.html 41 http://www.idef.com/idef1x.html 42 Kaplan, Robert S. and Bruns, W. Accounting and Management: A Field Study Perspective (Harvard Business School Press, 1987) ISBN 0-87584-186-4 43 Consortium for Advanced Manufacturing-International (CAM-I)

http://www.cam-i.org/


Business Process Modeling Notation (BPMN) A standard Business Process Modeling Notation (BPMN) provides businesses with the capability of understanding their internal business procedures in a graphical notation and will give organizations the ability to communicate these procedures in a standard manner. Furthermore, the graphical notation will facilitate the understanding of the performance collaborations and business transactions between the organizations.44

Through BPMN, architects create Business Process Diagrams (BPDs) based on a flowcharting technique tailored for creating graphical models of business process operations. A Business Process Model is a network of graphical objects, which are tasks, and the flow controls that define their order of performance.45

A BPD comprises four categories of graphical elements: Flow objects represent events, activities, and gateways.

Connecting objects connect flow objects.

Swim lanes and pools are a way to organize activities according to function.

Artifacts are extra information added to the process diagram.

Department of Defense (DoD) Architecture Methods The Department of Defense has a unique set of diagrams that required DoD-specific methods. These diagrams include:

Operational Node Connectivity diagram (OV-2)

Organization diagram (OV-4)

Business Rules diagram (OV-6a)

System Interface Description (SV-1)

System Communication Description (SV-2)

Application Portfolio Performance (SV-5)

System Evolution Description (SV-8)

Technical Standards Inventory/Profiles (TV-1)

Technical Standards Forecast (TV-2).

44 Object Management Group/Business Process Management Initiative 45 Introduction to BPMN, Steven A. White, IBM Corporation


Diagram/Method Mapping

Use Table 4 to determine which modeling standard to use when constructing DoDAF architecture products.

Architecture Product

DoDAF UML/ IDEF1X

IDEF0 BPMN English

AV-1 X

AV-2 X

AV-3

AV-4

AV-5

OV-1 X

OV-2 X X

OV-4a X

OV-4b X X

OV-5a X X

OV-5b X

OV-5c X

OV-6a X X

OV-6c X X

OV-6d X X

OV-7a X X

OV-7b X

OV-7c

SV-1 X

SV-2 X

SV-5 X

SV-8 X

SV-10c X X

TV-1 X

TV-2 X X

Table 4. Architecture Methods


NEXT STEPS There are two primary activities to undertake. First, it is important to develop the Mayor’s view of NYC business operations, which includes the Business, Performance, Service, Technical, and Data Reference Models. Next, the NEAF must be used to architect more capabilities. As more architecture information is created and collected, the usefulness of the NEA that is stored in the Architecture Repository will increase. The choice of capabilities should be based on investment decisions already made.

The reference models were started by the Department of Records and Information Services (Records) and the DoITT EAP. They are in the Citywide Architecture Repository and need to be vetted and developed further with the agencies as stakeholders. Records and DoITT have recommended to OMB and the PMAC that the vetting and evolution of these reference models, as the zoning maps for NYC Business Operations, be funded through the records retention revision effort underway at Records under a Mayoral mandate, through a Law Department contract, and that all the Citywide, Line of Business, and Agency-specific process information gathered by Records be put into the Citywide Architecture Repository. The Citywide Architecture Repository will then be the source of record for the process information required for evaluating funding requests and the source of record for retention policies, rules, and schedules.

All agencies, as the owners of the NEA, are welcome to join Records and DoITT in developing the reference models for use by this and subsequent administrations.

To begin using the NEA, it is important to realize that different sets of diagrams are required to architect different scenarios.

The choice of which capabilities to architect can be made based on the investment decisions proposed as part of PlanIT. DoITT has begun to architect some Foundational IT capabilities and some records and information management capabilities:

1. A Citywide Emergency Communications Call Center (911) capability — The System Integration Test Group within the Emergency Communications Transformation Program (ECTP) has developed a portion of the architecture for the Public Safety Answering Center (PSAC) I. ECTP has to create a complete set of NEAF-compliant blueprints to be used before the construction of PSAC II.

2. A Citywide Service Management capability — Service Management processes are those processes required to run a data center and establish service offerings. The specifications for these processes are defined by the Object Management Group (OMG) in their Information Technology Infrastructure Library (ITIL) specifications. DoITT Operations is currently using some ITIL discipline in managing the Citywide network (CityNet) and data center at MetroTech Center. In support of ECTP, DoITT created a set of NEAF-compliant blueprints for the service management of PSAC I. These blueprints are comprehensive but not complete enough to use for the construction of a Citywide Service Management capability.

3. A Citywide Licensing and Permitting capability —The NYC Business Express Program led by SBS used the precursor to the NEAF to architect a Citywide Licensing and Permitting capability. Because the information was gathered before the Citywide Architecture Repository was established, it resides in spreadsheets. This information should be imported into the Architecture Repository and the necessary blueprints created.

4. A Citywide Alert and Notification capability — The City funded a pilot project under the auspices of ECTP to establish a system that enables the residents of the five boroughs to register to receive alerts and notifications. This alert and notification capability should be architected and an Analysis of Alternatives should be conducted to see whether the New York State Mass Notification System can be used to support NYC’s alert and notification needs and if so, at what cost.

5. A Citywide Networking and Hosting capability —This capability provides networks and shared data center services to all agencies based on a single set of application, middleware, and protocol standards. The service management capability is a prerequisite for rationalized provision of these services.

6. A Citywide Architecture capability — The Citywide Architecture Capability and offering need to be architected so that NEA policy, organization, training, materiel (framework, process, methods, and tools), governance, leadership, personnel, and facilities can be established.


7. A Citywide Identity Management capability— This capability needs to be architected so that it supports Public Key Infrastructure (PKI)-based identification cards for building access and also as keys that enable access to Citywide mobile assets such as Department of Transportation cars, FDNY fire trucks, and all agency mobile computer equipment.

Table 4 is included here as part of the NEAF to guide users of the framework in deciding which diagrams are useful for the purposes listed.

The Lines of Business should begin analyzing their business and operational landscape for Line of Business-specific and Citywide capabilities.

Table 4. Scenarios and diagrams


APPENDIX

Related Documents The following documents contain information that is relevant to developing an Enterprise Architecture.

A Different Kind of Life Cycle: The Zachman Framework (David C. Hay, Essential Strategies, Inc.)

A Framework for Information Systems Architecture (John A. Zachman, IBM Systems Journal, Vol. 26, No. 3, 1987)

A Practical Guide to Federal Enterprise Architecture (Chief Information Officer Council, Version 1.0, February 2001)

Business Enterprise Architecture (BEA) Architecture Development Methodology (ADM) (Department of Defense Business Management Modernization Program (BMMP))

City of New York Information Technology Strategic Direction

Department of Defense Architecture Framework, Version 1.0, Volume 1: Definitions and Guidelines

Department of Defense Architecture Framework, Version 1.0, Volume 2: Product Descriptions

Enterprise Architecture: What Is It and Why Do It? (Anthony Insolia)

FEA Consolidated Reference Model Document, Version 2.3, October 2007

IBM Rational Approach to DoDAF, Part 1: Operational View

IBM Rational Approach to DoDAF, Part 2: Systems View

PlanIT, New York City Technology Plan

NEA Document Set This Citywide Enterprise Architecture Framework and Methods document is the second of nine volumes that describe the NEA:

1. Governance and Policy 2. Framework and Methods 3. Process (Activities, Tasks, Work Products, and Methods) 4. Guidelines, and Standards 5. Procurement and Legal Guidance 6. Independent Verification and Validation 7. Costing Models 8. Tool Environment, Administration and Use 9. Training


Role Definitions

Chief Architect

Responsibilities The Chief Architect46 has primary responsibility to implement and maintain the architecture of Citywide, Line of Business, and Agency-specific capabilities in accordance with the NEAF. This person is skilled in relationship building, process development and improvement, program and project planning, and staff development. The Chief Architect is not the source of architecture content, but the person that understands the architecture and engineering activities, tasks, methods, work products, and deliverables that are a by-product of the program life cycle. He or she is a facilitator of the architecture’s development.

The scope of the Chief Architect's role includes leading the creation and evolution of the NEA program, including the coordination of an appropriately balanced pursuit of enterprise business, information, technical, and solution architecture viewpoints; understanding, advocating, and supporting the enterprise's business and IT strategies; leading the identification and analysis of enterprise business drivers to derive enterprise business, information, technical, and solution architecture requirements; analyzing the current business and IT environment to detect critical deficiencies and recommend solutions for improvement; analyzing industry, technology, and market trends to determine their potential impacts on the enterprise; promoting the NEA process, outcomes, and results to the organization, including the enterprise's IT and business leaders; leading the development of an implementation plan for the NEA, based on business requirements and IT strategies; ensuring that the optimal governance structure and compliance activities are associated with NEA compliance; overseeing NEA implementation and ongoing refinement activities; consulting with program and project teams to fit solutions to architecture across all viewpoints; identifying organizational requirements for the resources, structures, and cultural changes necessary to support the NEA; overseeing the documentation of all architecture design and analysis work; leading the development and execution of a communications and education plan for the NEA; assessing through appropriate metrics and communicating the achievement and impact of the NEA.

Qualifications The Chief Architect has an advanced degree in management, computer science, computer engineering, electrical engineering, system analysis or a related field of study. His or her professional experience includes a minimum of five years of experience in at least two business disciplines (such as business or IT strategic planning; line management; business, information or technical architecture; IT management; application development; middleware; information analysis; and database management or operations) in a multi-tier environment. He or she is skilled with the Enterprise Architecture Frameworks and the industry-standard methods on which the NEAF is based. Alternatively, the Chief Architect may have education and experience equivalent to the above.

46 Robert A. Handler and Deborah Weiss, Role Definition and Organization Structure: Chief Enterprise Architect (Gartner Research, 31 March 2006)


Enterprise Architect

Responsibilities The Enterprise Architect47 has responsibility to manage establishing planner level architecture detail and manage recording that information into the NEA tool environment; guide other organizations and programs on architecting Citywide capabilities; assist in the maintenance and administration of the EA tool environment; manage the evolution of the NEAF documentation; develop training material for teaching others how to use the NEAF and tool environment; provide detailed functional system analysis and documentation of user and system requirements for new projects or programs being proposed within the City by reviewing the design and analyzing the business processes and business cases; provide data modeling; design graphical user interfaces; determine the impacts of human factors on application design and development; serve as a project manager and subject matter expert in setting group expectations and improving group information flow and communications; interface with system engineers and developers on projects and programs; perform testing and developing of test cases and plans; write user documentation; memorialize and publish current and target architectures, including the design of functional and logical application architectures and data architecture definitions.

Qualifications The Enterprise Architect has a Master's Degree in computer science from an accredited college and three years of progressively more responsible, full-time, satisfactory experience using mainframe, mini-computer, or micro-computer technology in computer applications programming, systems programming, computer systems development, data telecommunications, data base administration, or planning of data processing. At least 18 months of this experience should have been in an administrative, managerial, or executive capacity in the areas of computer applications programming, systems programming, computer systems development, data telecommunications, data base administration, planning of data processing, or supervision of staff performing these duties. Alternatively, the Enterprise Architect may have education and experience equivalent to the above.

Sample Solicitation Language The City envisions accomplishing goals and objectives using best practices in program management, portfolio management, strategic planning, service management, and enterprise architecture. The Contractor or Proposer (use one) shall lead the architecting of capabilities or solutions based on the Citywide Enterprise Architecture Framework (NEAF). For each capability being proposed, the Contractor or Proposer (use one) shall provide an analysis of alternatives based on the NEAF that demonstrates leverage of existing City architecture, components, platforms and processes.

The contractor shall apply the NEAF to gather information required for the planning, design, and implementation of the scope of work and desired capabilities of this solicitation. The information gathered and/or discovered shall be recorded using the Citywide Enterprise Architecture (NEA) application tool and the architecture shall be stored in the NEA Architecture Repository. The contractor shall deliver all reference or collateral material in the Architecture Repository specified by the City. The architected information shall include but not be limited to:

1. Identifying information and a clear explanation of goals, objectives, and performance measures 2. Requirements, gaps, and issues to be addressed 3. A dictionary of terms

47 City of New York, Department of Information Technology and Telecommunications, Job Vacancy Notice, JVN: 858-2009-001700


4. A Capability Maturity Model 5. Best practices 6. Findings and recommendations 7. Capabilities and underlying services defined in terms of the people, processes, and tools that

facilitate the delivery of the services 8. Design, implementation, and operational cost information 9. Organization information and models, including a mapping of services to the organizations that

provide them 10. User communities 11. Process information including but not limited to roles, business rules, data, tasks, triggers, and

outcomes 12. Information exchange requirements between user communities and information exchanges

between processes that realize the information exchange requirements 13. System data exchanges mapped to the process information exchanges 14. System, application, middleware, and product information 15. Supplier information 16. Technical standards and forecast information 17. Policy and training information 18. Milestones and plans

The information gathered by the contractor and architects must conform and adhere to the architecture principles of the NEAF (Attachment). The information shall document the existing conditions and the proposed environment. The contractor and architects shall provide NEAF-compliant transition plans documenting how to get to the proposed environment and an associated timeline. The contractor shall ensure that the architects document a clear alignment between all elements of the architecture and the goals and objectives they are designed to realize.

Glossary ADM Architecture Development Methodology

AF Architecture Framework

AIA American Institute of Architects

AoA Analysis of Alternatives

AV All Views

BEA Business Enterprise Architecture

BOP Business Operations

BPD Business Process Diagram

BPMN Business Process Modeling Notation

BRM Business Reference Model

CAC Citywide Architecture Capability

CCC Citywide Collaboration Capability

CMMI Capability Maturity Model Integration

CNC Citywide Network Capability

COE Common Operating Environment

COI Community of Interest


CONOPS Concept of Operations

COTS Commercial-Off-the-Shelf

CPR Citywide Performance Reporting System

DCC Data Center Capability

DoITT Department of Information Technology and Telecommunications

DOTMLPF Doctrine (Policy), Organization, Training, Materiel, Leadership, Personnel, and Facilities

DoD Department of Defense

DoDAF Department of Defense Architecture Framework

DOT Department of Transportation

DRM Data Reference Model

EA Enterprise Architecture

EAB Enterprise Architecture Board

ECC Emergency Communications Capability

ECTP Emergency Communications Transformation Program

ED Economic Development

EPC Emergency Public Notification Capability

ESM Enterprise Service Management

FDNY Fire Department of New York City

FEA Federal Enterprise Architecture

FEAF Federal Enterprise Architecture Framework

FIT Foundational IT

FRN First Responder Network

FRP Finance Resource Planning

GOTS Government-Off-the-Shelf

HHS Department of Health and Human Services

ICAM Integrated Computer-Aided Manufacturing

IDEF Integrated Definition Family

IDM Citywide Identity Management

IER Information Exchange Requirement

IOT&E Initial Operational Test and Evaluation

IT Information Technology

ITIL Information Technology Infrastructure Library

ITMRA Information Technology Management Reform Act (Clinger-Cohen Act)

LOB Line of Business

LPC Licensing and Permitting Capability

NYC The City of New York


NEA NYC Enterprise Architecture

NEAF NYC Enterprise Architecture Framework

NEAP NYC Enterprise Architecture Program

NYPD New York City Police Department

NYS New York State

OEM Office of Emergency Management

OMB Office of Management and Budget

OMG Object Management Group

OV Operational View

PAF Project Approval Form

PKI Pubic Key Infrastructure

PlanIT The City of New York Strategic IT Plan

PMAC Portfolio Management Advisory Council

PMC Portfolio Management Capability

PRM Performance Reference Model

PSAC Public Service Answering Center

Records Department of Records and Information Services

SADT Structured Analysis and Design Technique

SBS Department of Small Business Services

SEI Software Engineering Institute

SPB Strategic Planning and Budgeting

SRM Service Component Reference Model

SV Systems View

TRM Technical Reference Model

TV Technical Standards View

UML Unified Modeling Language

XML Extensible Markup Language

XSD XML Schema Definition
