NYC NEA Framework and Methods - Web v1.1

8/14/2019 NYC NEA Framework and Methods - Web v1.1

1/46

Public 04/07/09

Citywide

Enterprise ArchitectureFramework and Methods

v1.1

Anthony InsoliaDirector, Enterprise ArchitectureCity 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 InformationTechnology and Telecommunications (DoITT) to describe the Citywide Enterprise ArchitectureFramework of the City of New York, define the Citywide Enterprise Architecture policy, andoutline its benefits for City governance. The primary audiences for this document are City agencyChief Information Officers and Chief Architects who will develop architectures using industrystandard methods as described in the Citywide Enterprise Architecture Framework. The City ofNew York is hereafter referred to as NYC or the City.


2/46

Public 04/07/09 ii

Document Revision History

Version Date Description Name

1.0 11/21/08 Initial Draft Anthony Insolia

1.1 04/07/08Changed document classification fromFor Official Use Only to Public

Gary Alden


3/46

Public 04/07/09

CONTENTSEXECUTIVE SUMMARY .................................................................................................................. vTHE NEA AND ITS USES ............................................................................................................... 1

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

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

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

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

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

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


4/46

Public 04/07/09 iv

Process Context and Performance ..................................................................................... 23Process Information Flow ................................................................................................... 24Business Rules ................................................................................................................... 24Process Details ................................................................................................................... 24Capability and Services Training ........................................................................................ 25

Data Model.......................................................................................................................... 25Data State ........................................................................................................................... 25XML Representation of Data .............................................................................................. 25

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

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

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

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

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

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

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

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


5/46

Public 04/07/09 v

EXECUTIVE SUMMARYThe Citywide Enterprise Architecture (NEA) is an executive-level discipline and tool that facilitatesCity 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 operationsand 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-basedportfolio management means viewing City government as a single enterprise with acomprehensive 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, ora 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 Citys portfolio of capabilities promotes a deeper understanding of the costs,risks, and performance of Cityactivities.

Two triggers initiate the collectionof architecture information:

portfolio gaps and portfolio issues.Portfolio gaps are missingcapabilities, while portfolio issuesare problems with existingcapabilities.

Architecture quantifies andqualifies gaps and analyzesindustry offerings to createblueprints that document how thegaps should be addressed.

Architects also analyze existingblueprints to pinpoint issues and

to check for the fit and finish ofsolutions to the issues.

In both cases, whether gaps orissues are identified, architecturecreates portfolio recommendationsand transition plans that supportinformed funding decisions.

Enterprise Architecture is based on the metaphor of traditional building architecture. Prospectivehomeowners as clients engage architects to gather information about their ideas for a house, andthe architects transform their requirements into specific plans that can then be designed byengineers and constructed by builders. The architects plans are blueprints. In the same way,enterprise architects gather information from business owners about desired capabilities tospecify requirements and business rules, which are used to develop scoping and needs analyses.The diagrams of the enterprise architect correspond to the blueprints of the building architect.Whether architecting a business or a house, plans and costing models are necessary tounderstand the cost, facilitate informed decisions, and ensure that owners get what they wantfrom the builders. Figure 1 shows this basic process and its flow where the information beinggathered on the blueprints is being placed in the Architecture Repository. This repository

1ITIL Glossary of Terms and Definitions, ITIL V3 Glossary, v01, 30 May 2007

Figure 1. Architecting a house or a business


6/46

Public 04/07/09 vi

becomes the source of record for strategic plans, operational aspects of NYC as a business, andthe underlying IT infrastructure supporting the business. More importantly, this repositorybecomes a baton that is passed off from administration to administration. This repository isdepicted again in Figure 2 to show that architecture information is being gathered in numeroussystems and without regard for data standardization. Just as the American Institute of Architects(AIA)

2provides standards for architecting buildings, the Citywide Enterprise Architecture

Framework (NEAF) provides the standards for architecting the City as a business and ensuringthat what is built is aligned with strategic goals and objectives as defined in PlanIT3, the CitywidePerformance Reporting System (CPR), and other planning tools.

The NEA combines the architecture information into a federated Citywide structure and repositorythat defines the mission, goals, and objectives of the City as an enterprise. The NEA defines thepeople, processes, information, and tools needed to perform the Citys mission. It defines theplans for implementingtechnologies to support thatmission and achieve the goalsand objectives of Citygovernance.

Enterprise Architects use theframework to architect

capabilities for business owners.The NEA contains the blueprintswith the appropriate level ofcosting information that theOffice of Management andBudget (OMB) needs to approveinvestments in new capabilitiesor in the augmentation ofexisting capabilities.

The NEA is therefore a planningand investment managementtool. The NEAF is the basis forgathering, organizing, anddepicting information aboutcurrent City functions toundertake a rigorous analysis ofthe risks, benefits, andalternatives when planning alltransformations of current activities and future development. The NEA displays the informationwith deep levels of specificity embedded in diagrams. This enables greater rationalization ofplanning, which drives down costs and improves the management of investments, suppliers, risk,contracts, and business maturity.

Architecture enables City government to take fuller advantage of existing infrastructure andassets. It saves time, saves money, reduces risks, ensures program alignment with City missions,and increases the coordination and oversight of a continuing process of improving all City

activities. As an example, the City saves money every time a supplier is engaged because theNEA has blueprints that document the operational and systems landscapes, which reducesrediscovery.

2The American Institute of Architects (AIA): About the AIAhttp://www.aia.org/about_default

3PlanIT, New York City Technology Plan

Figure 2. Architecture Repository


7/46

Public 04/07/09 vii

The NEA is relevant in the following management areas:

Investment/Portfolio Management: The NEA simplifies the OMB evaluation of portfoliorecommendations by creating a standardized approach for analyzing and recording alternatives,identifying reuse opportunities, eliminating redundancy, developing business cases, managingcosts, 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 referencepurposes when funding requests are being evaluated. Following the maxim Architect once, deploymany, the NEA solves problems as a class instead of individually. For example, it is much moreefficient 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 ofprocesses and information to enhance delivery and quality and drive costs down.

Supplier Management: The NEA defines activities, tasks, methods, work products, anddeliverables. Architecture also eliminates rediscovery costs by recording information instandardized form.

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

Maturity Management: The NEA helps the City mature as an enterprise by standardizingprocesses, 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 justInformation Technology (IT). It is a repository for information about all City business operations. Itbelongs to the whole City and is platform and vendor neutral.


8/46

Public 04/07/09 1

THE NEA AND ITS USESIn 1996 the Federal government established the Information Technology Management ReformAct (ITMRA, now the Clinger-Cohen Act),

4which 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 Managementand Budget, issued a memorandum with the subject line "Funding Information SystemsInvestments." The memo was quickly renamed Raines' Rules

5and became a seminal

document for guiding how agencies purchase information technology. The rules, as outlined inthe 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 supportthe 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 usesof 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 retainingflexibility 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 aspracticable, each of which solves a specific part of an overall mission problem and delivers ameasurable net benefit independent of future chunks.

8. Employ an acquisition strategy that appropriately allocates risk between government and thecontractor, effectively uses competition, ties contract payments to accomplishments, and takesmaximum 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 informationrequired to answer those questions.

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

An enterprise is an organization supporting a defined business scope and mission, includinginterdependent resources (policy, organization, training, systems, people, processes, tools,leadership, and facilities) that must coordinate their functions and share information to support acommon set of interrelated missions.6The government of the City can be viewed as a singleenterprise, 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. Amethod is an

4Public Law No. 104-208 of 1996, National Defense Authorization Act , Division E - Information Technology

Management Reform (Clinger/Cohen Act)

5OMB Memorandum of October 25, 1996, Subject: Funding Information Systems Investments

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

February 2001)


9/46

Public 04/07/09 2

organized body of techniques for gathering information, integrating or correcting previousinformation, and applying a systematic approach to the design and construction of architecturediagrams to encompass and express that information. Enterprise Architecture (EA) is a strategicinformation asset base that defines the enterprises mission, information necessary to perform themission, and the plans for implementing technologies to support that mission and to respond tochanging mission needs.

7

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

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

The architect views City government from a portfolio management perspective, as a collection ofLines 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 runapplications that automate processes. The capabilities are associated with Goals, Objectives, andStrategies, and can cross the boundaries of the agencies and other organized bodies. Viewingthe City as an enterprise in this way provides a simplified and comprehensive vision of the Citythat facilitates Citywide Portfolio Management.

NYC Enterprise Architecture (NEA) Defined

The enterprise called City government traditionally has been viewed as a collection of agencies

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

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

NYC, one City

is divided into five boroughs

NYC government, one enterprise

is divided into tenLines of Business


10/46

Public 04/07/09 3

and other organized bodies such as councils, commissions, boards, departments, and similarofficial entities. This view is shown by standard organization charts. From this outlook, agencyservices are often seen as isolated projects. The Mayoral goals of accessibility, transparency andaccountability, however, promote an alternative view of City government from a portfoliomanagement perspective, which is the Line of Business view described above. This is theperspective 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 technologicaland a business perspective. In the architecture and design of buildings, architects and engineersdesign buildings that fit within building zones and satisfy zoning ordinances. The NEA architects

capabilities for the City that fit within Lines ofBusiness and that satisfy mission objectives.In the same way that the AIA promulgatesstandards for building design andconstruction that the City enforces thoughbuilding codes in different zones of the fiveboroughs, the NEAF establishes standardsfor architecting business operations both

Citywide and within the zones of the tenLines of Business.

When architects plan for the construction ofbuildings, they begin with models anddiagrams of the proposed building. For

example, they might create a sketch of a two-story home on the corner of a residential street. Thearchitects specify the size, shape, and intent of the building. In effect, they are determining thescope of the building. Next they create diagrams that show the structure and how electricity, heat,water, and telephone service are provided to the building. Then they continue to drill down, in a

Figure 6. Line of Business (zone) and capabilityinformation

Figure 5. Zone and building information


11/46

Public 04/07/09 4

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

Similarly, Enterprise Architects plan for the construction of business capabilities. A businesscapability 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 ofBusiness 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 isanalogous to the subdivision of the City into boroughs.

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

In the same way that the City collects information about building architecture and enforcesbuilding codes, enterprise architecture collects information about Line of Business capabilities

and ensures that standards are developed and business rules are followed in the design andconstruction 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-specificcapabilities is described in later sections of this document.

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

NYC Enterprise and Portfolio DefinedThe enterprise called the City is a group of more than forty agencies that supplies services to thepublic and runs the City. These agencies collectively represent ten Lines of Business (LOBs), orareas 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 thanorganizational partitions. The City Lines of Businesses are as follows:

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

Economic Development: This LOB centers on improving the long-term financial stability of the Cityby improving financial management, collaboration, and efficiency; streamlining and automatingsupport 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 Policeand 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 andrelated services, including food and shelter, employment, and child care, to those New Yorkers inneed of assistance.

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


12/46

Public 04/07/09 5

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

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

Citywide Administration: This LOB represents the continual effort to improve efficiency and reducethe 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 allthe other LOBs, and focuses on computer applications, telecommunications, and records andinformation management.

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

Citywide capabilities that span Line of Business boundaries. These capabilities provide services tothe public while providing for the Mayoral goal of transparency. They do this by treating the Lines ofBusiness as trading partners with information exchange requirements that make the Lines ofBusiness and the underlying agency boundaries transparent to the public. An example is theCitywide 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 SafetyLine of Business capability called Emergency Public Communication being delivered by the NotifyNYC program owned and operated by the Office of Emergency Management (OEM).

Agency-specific capabilities such as the Inmate Custody Management capability of the Departmentof 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 forachieving goals and objectives. Since the portfolio of capabilities includes Citywide, Line ofBusiness-specific, or Agency-specific capabilities, the NEA divides NYC Business Operations intoa Citywide section, a Line of Business section, and a section to accommodate all Agency-specificcapabilities. Viewing City functions in this way can provide an unimpeded, less fragmented, andmore comprehensive view of City activities.

The NEA is built one capability at a time and one perspective at a time. Everyone in theenterprise contributes to the building of the NEA. Deputy Mayors and Agencies produce aMayors view of the enterprise on behalf of the Mayor. Figure 7 shows the Mayors view of theCitywide portfolio. The Mayors view divides the City into LOBs, records the dependenciesbetween Lines of Business, and details Citywide capabilities. Deputy Mayors also develop LOBviews of the enterprise. Figure 8 shows the Deputy Mayoral view of a LOB as a collection ofcapabilities. Agency Commissioners and Chief Information Officers provide Agency-specific and

program-specific views containing detail suitable for systems integrators to engineer end-to-endsolutions. Systems integrators provide the engineering and integration detail and subcontractorsdeliver piece parts and information about the environment as built when it varies from thearchitecture or plan.

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


13/46

Public 04/07/09 6

capabilities have known operational costs and expected lifespans. New capabilities areestablished to fill gaps. Workgroups are formed to analyze the gaps and architect the capability tofill the gaps. The strategic planning process and the execution of architecture activities and tasksare 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 thesetriggers. 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 portfoliorecommendations and AoA. Figure 9 shows the life cycle for an acquisition program. Architectureactivities, tasks, work products, deliverables, methods, and roles are applied within a standard setof program phases. The AoA is shown along with the phases of the program, and the milestonesthat enable the governance process and architecture reviews.

The program life cycle depicted in Figure 9 outlines the phases ofprogram management. The program life cycle provides theunderpinnings of the governance process, and frames thearchitecture activities and tasks that result in standard architecturework products and deliverables. The work products and deliverables

are required at the milestones depicted as diamonds.The architecture information about a capability is continuallygathered and refined. The architecture description is arepresentation of a current or postulated real-world configuration ofresources, rules, and relationships that enables the City to manage

IT efficiently as astrategic resourceand business-process enabler. Inthis way, the NEAdirects informeddecision-makingand helps to mature

the enterprise.

Developingarchitecture is aprocess ofgatheringinformation todefine anddocument specificattributes of thecapabilities andtheir programs. Asthe information isgathered and the

programs andprocesses arediagrammed, theinformation that isgathered iscollected in the

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

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

To the Deputy Mayors,the portfolios for eachLine of Business are acollection of capabilities

Figure 8. Deputy Mayor (Line ofBusiness) portfolio

Figure 7. Mayors (Citywide) portfolio

To the Mayor, the Citys portfolio

is divided into ten Lines of Business


14/46

Public 04/07/09 7

the analysis and develop NEAF-compliant documentation and blueprints for capabilities in theCitys portfolio. As the information is collected and diagrammed, gaps and issues become moreapparent, as well as opportunities to avoid redundancies of effort and leverage the reuse ofexisting resources.

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

Goals, objectives, and performance measuresaligned with Mayoral goals and objectives

The list of data and authoritative sources withinscope

The list of services and processes within scope

The list of physical locations that need to beconsidered

The list of parties, agencies, and user communitiesto be considered

Timing considerations and business events that arein scope

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

The result is the creation of a strategic plan, with aMayors view of each capability and an associated portfolio recommendation. Portfoliorecommendations based on architecture analysis and including Mayoral-view detail are providedto the Chief Information Officer (CIO) Council.

Building the Enterprise

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

Figure 9. Program Lifecycle

Figure 10. Repository Tool


15/46

Public 04/07/09 8

programs adherence to policies and standards in the functional areas of Security, EnterpriseArchitecture, Network Policy, Information Utility, and Application Development.

Agencies and the programs they own are responsible for capabilities directly associated withprioritized strategic goals and objectives. Programs are launched based on functional needs andarea analysis performed using architecture methods. Some of the information required to lay thefoundation 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 launchthe program.

In creating the architecture-based PAF, the program has already executed a portion of theconcept phase, and a piece of the architecture is then complete. The program next has to godeeper 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

programs. These programs are the delivery mechanisms for the architecture and the actualfacilities and systems that house and automate the services that comprise the capability. Figure11 also shows the Architecture Repository as the warehouse of all information about allcapabilities regardless of which program is producing the architecture information.

Figure 11. Enterprise Lifecycle


16/46

Public 04/07/09 9

Using the Architecture

The NEA and NEAF provide many benefits to the City. Architecture can be used to analyze therisks, benefits and alternatives more rigorously when planning transformations of current activitiesor future development. Used as a planning and investment management tool, architecturerationalizes the use of limited resources and by more thorough and coordinated planning, it freesup money for new projects. Therefore an investment in architecture pays dividends in costsavings, and by increasing efficiency and effectiveness, it enables City government to do morewith less.

The Mayor benefits by seeing that the portfolio of capabilities associated with each Line ofBusiness is aligned with mayoral goals and objectives. The Mayor also benefits by having asingle source of information about the health of NYC Business Operations and the cost of thecapabilities 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 areresponsible. The architecture provides an understanding of planned, budgeted, and actual dollarsbeing spent and the distribution of that money across the portfolio of capabilities and the agenciesthat 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 andexpense, and maximize the use of existing resources. It can clarify the mechanisms for achievingagency goals and objectives, or make plain any better alternatives. It can improve themanagement of investments, suppliers, risk, contracts, and business maturity.

To obtain these benefits, however, the first step is to begin architecting. The EnterpriseArchitecture Program (EAP) owned by DoITT is assisting this effort to begin architecting bydeveloping 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 veryblueprints the NEAF calls for. This environment, the people doing the architecture work, and thearchitecture training will be available as a service offering to the City at large. Agencies willbenefit from not having to make a duplicate investment in their own architecture toolenvironments.

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 bea requirement in any solicitations for projects involving new capabilities or substantive changes tocurrent capabilities.


17/46

Public 04/07/09 10

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

Zachman Framework

John Zachman published an article in 1987 that presented a blueprint for change management inbusiness, known as the Zachman Framework, which has since become an industry-standard.

8

According to Zachman, the architecture for an enterprises systems should support theenterprises business objectives. From that architecture, the strategic plan of the enterprise canbe understood.

Zachman uses the construction analogy to define the components of the enterprise: systems, likebuildings, require blueprints. The first step in applying the Zachman Framework is to understandthe 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, andsubcontractor. 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 designedto facilitate informed decision-making. To understand what information is gathered whenarchitecting a capability, the following question is asked:

What decisions are the planner, owner, designer, builder and subcontractormaking 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 thebottom, the perspective becomes narrower and the information becomes more detailed. Each cellin the Zachman Framework contains information representing a different aspect of thecapability.

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

3, 1987)


18/46

Public 04/07/09 11

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

Department of Defense Architecture Framework(DoDAF)

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

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

The Overview architecture diagrams (known All View or AV architecture diagrams) describe thescope 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 architecturediagrams.

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

The NEA is described using about two dozen architecture diagrams, which are presented in thenext section. These diagrams are the metaphorical painting canvases on which the picture of theenterprise is created by gathering the information required by the planner, owner, and designengineer. 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 offive interrelated reference models designed to facilitate cross-agency analysis and theidentification 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 ofManagement and Budget (OMB) built the following reference models:

The Performance Reference Model (PRM) as a standardized framework to measure theperformance of major IT investments and their contribution to program performance. Thesemeasurements are used by agencies to better manage the business of government at a strategiclevel, by providing a means for using an agencys EA to measure the success of IT investmentsand their impact on strategic outcomes.

10

The Business Reference Model (BRM) is a function-driven framework for describing businessoperations of the Federal government independent of the agencies that perform them. It presents afunctional (rather than organizational) view of the Federal governments 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 functionalframework that classifies service components with respect to how they support the business. It

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

10FEA Consolidated Reference Model Document, Version 2.3, October 2007



19/46

Public 04/07/09 12

identifies and classifies horizontal and vertical service components supporting Federal agenciesand 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 ofapplications, application capabilities, components, and business services.12

The Technical Reference Model (TRM) is a component-driven, technical framework used to identifythe standards, specifications, and technologies that support and enable the delivery of servicecomponents and capabilities. It provides a foundation to advance the reuse and standardization of

technology and service components from a government-wide perspective. Aligning agency capitalinvestments to the TRM leverages a common, standardized vocabulary, allowing interagencydiscovery, collaboration, and interoperability. Agencies benefit from economies of scale byidentifying 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 andinformation that support program and business line operations. Using a flexible and standards-based framework enables information sharing and reuse across the Federal government via thestandard description and discovery of common data and the promotion of uniform datamanagement 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





20/46

Public 04/07/09 13

The NEA Framework (NEAF)

The NEA Framework is built from elements of the three foundational frameworks describedabove. From the Zachman Framework the NEAF takes the matrix of views; from the DoDAF, thediagrams; and from the FEAF, the reference models. Industry-standard methods for creatingdiagrams 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 oflanguages, Activity-Based Costing (ABC), Business Process Modeling Notation (BPMN), and themethods of the Department of Defense Architecture Framework (DoDAF). These methods aredescribed 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 becausethat is all that was needed. The matrix works like the game show Hollywood Squares. In each cellare placed questions that need to be answered. We then specify what information needs to gointo the architecture and be accessible via that cell in order to answer the questions.

The NEAF usesonly the first three

rows of theZachmanFramework.Capabilities beingarchitected have aplanner, owner, anddesign engineersview.

In architecting acapability, we firstestablish aplanners view. Thelist of informationrequired in aplanners view of acapability is thatinformation requiredby a City planner todecide whether thecapability should bepart of the strategicplan. If thecapability is put intothe strategic plan,then it is assigned astart date. When

the start datearrives, thearchitect gathersand records theinformation requiredfor the owners viewof the capability.

Table 2. Matrix information in Zachman Framework


21/46

Public 04/07/09 14

What We Took From the DoDAF

Put simply, we took diagrams. We use the diagrams to organize and depict the information wegather to answer the questions in the Hollywood Squares. The Zachman Framework provides thestructure to house DoDAF architecture diagrams. It was necessary to create additional diagramsbecause the DoDAF is incomplete.

For each capability in NYCs Strategic IT Plan (PlanIT), the NEA will contain some combination ofthe following architecture diagrams. The distribution of these diagrams in the cells of theZachman 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. OperationalCommunities/TradingPartners (OV-2)

3. Capability and ServiceTaxonomy (OV-3a)

4. Service to ProcessMapping (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 InformationFlow (OV-5c)

10. Business Rules (OV-6a)

11. Process Details (OV-6c)

12. Capability and ServicesTraining (OV-6d)

13. Data (OV-7a)

14. Data State (OV-7b)

15. XML Representation ofData (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)

Table 3. Diagrams in Zachman Framework


22/46

Public 04/07/09 15

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 Mayors 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, DeputyMayor/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. Inthe Mayors view of the City, we collectively refer to certain BOP diagrams using the ReferenceModel 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 businessoperations from a Mayors 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 Mayors 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


23/46


24/46

Public 04/07/09 17

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


25/46

Public 04/07/09 18

ARCHITECTURE DIAGRAMSArchitecture diagrams, also known as blueprints, are those graphical, textual, and tabular itemsthat are developed in the course of architecting a capability. Diagrams describe thecharacteristics of a capability and the purpose of each diagram for the people that will use it.

15

Diagrams are also used to establish the Mayors view of the City. The Mayors view, whose

purpose is to zone the enterprise and establish the ordinances for architecting capabilities, iscomprised of reference models comprised of diagrams.

The framework for the federated Citywide Enterprise Architecture includes the FEAF ReferenceModels 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 otherarchitecture 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 architects means of recording and portraying basic information about thecapability. Since the NEAF is a set of standards for architecting capabilities, it also specifiesstandards 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 othersdescribe proposed conditions for capabilities that do not yet exist. The diagrams that documentexisting conditions are called as-is diagrams. Those that describe proposed conditions are theto-be diagrams. One special diagram, which is described in more detail later, is the SystemEvolution Description diagram, which documents the transition from the as-is to the to-be. Thisdiagram 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 describeeach diagram and the artifacts that can be placed on each one, with a focus on the purpose ofthe 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 ofartifacts 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

15DoDAF, Volume I, 5

16adapted from Defense Business Transformation Agency homepage,

http://www.defenselink.mil/DBT/products/2007_BEA_ETP/bea_4_1.html


26/46

Public 04/07/09 19

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 workingon particular subsets of processes, and collections of roles called pools)

23. Data Class

24. Business Object25. 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 architecturediagrams. The Overview architecture diagrams provide basic background and identifyinginformation about the capability as well as findings and recommendations. The Overviewarchitecture diagrams are described below.

Capability Overview

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

17

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

Background and drivers

Definition

Purpose and viewpoint

17DoDAF, Volume II, 3.1.1


27/46

Public 04/07/09 20

Context

Tools and file format used

Findings

Dictionary

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

19

In the Dictionary one lays down architecture artifacts called terms, just like in a traditionaldictionary. The terms are created for all concepts that are not defined elsewhere in thearchitecture of the capability. The Dictionary of complete concepts and terms is generated bycollecting all the concepts, whether explicitly created as terms in the dictionary diagram orsourced 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 complexData 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. Itspecifies 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 aparticular release of the architecture addresses material weaknesses and best practices.

In recording goals, objectives, strategies, and maturity levels in the architecture and associatingall other business and system artifacts with these goals, one uses the architecture to ensure that

all policies, organizations, training, processes, systems, technology enablers, governancestructures, staffing, and facilities are aligned with goals and objectives.

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

Business Case

The Business Case diagram defines how the resources and business processes support thebusiness. The business case for a capability is determined using the cost information stored inthe architecture. It is computed by adding up all the benefits that can be articulated in a dollaramount and subtracting the total development and maintenance/support costs. Therefore the

architecture must enable the architect and engineers to record all development/startup andmaintenance costs.


19A Practical Guide to Federal Enterprise Architecture (Chief Information Officer Council, Version

1.0, February 2001)


28/46

Public 04/07/09 21

Requirements

Requirements define the functional and technical or non-functional needs of the capability. TheRequirements diagram enables the architect to record requirements hierarchically and toassociate the requirements with the services of the capability. The capability taxonomy and thedecomposition 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 completedescription of what a use case is and how to create one is found in documentation provided bythe standards bodies that own the Unified Modeling Language (UML) used to create use casesand scenarios.

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

Operational Diagrams

The Operational diagrams focuses on the operational or business aspects of the capability. Theydescribe 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 keyconcepts and differentiators or interesting or unique aspects of the capability that make it differentfrom how business is currently being conducted. The Operational Concept and Vision provides aquick, high-level description of what the capability is supposed to do and how it is supposed to doit. 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 artists rendering or, insome 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, andaccountability. This is an example of a concept of operations (CONOPS) diagram, which is basedon the Porter Value Chain 21 business model, which defines a value chain as a series of variabledelivery pipes between customers and suppliers. The operation of the pipes is transparent to thecustomers.

The Porter Value Chain is a strategic concept used to analyze the activities required to operatean enterprise successfully. The value chain comprises five primary generic activities (inboundlogistics, 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, inwhich the enterprise is a system made up of subsystems. Each subsystem has inputs,transformation processes, and outputs. Every input, transformation process, and output requiresthe acquisition and consumption of resources. The effectiveness and efficiency of this acquisitionand consumption are reflected in the value of the enterprise.


21Michael Porter, Competitive Advantage: Creating and Sustaining Superior Performance (1985)


29/46

Public 04/07/09 22

Operational Node/User Group Connectivity

The Operational Node/User Group Connectivity diagram is a key component of the Operationaldiagrams that records user groups or user communities and the information exchangerequirements (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 actualinformation-exchange requirements that need to be addressed by actual information exchangesbetween operational activities recorded in the activity model. The graphic includes internaloperational nodes (internal to the capability) as well as external parties. This architecture productis 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 andthe cost for implementing them, the Information Exchange Requirements can be considered incosting a capability.

Capability and Service Taxonomy

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

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

Service-to-Process Mapping

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

Having this mapping ensures the business that it knows what processes and accompanyingresources 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 asthe segue to the world of engineering and design where we list what people traditionally think ofas architecture: systems and applications.



30/46

Public 04/07/09 23

Organizational Structure

The Organizational Structure diagram is similar to an organization chart. It illustrates the structureor relationships among the organizational units that are the key players in delivering andoperating the capability. This diagram clarifies the various relationships that exist between

organizations and sub-organizations, and between internal and external organizations.23

Oncethe organizational units and the relationships between them are established, services aremapped to the organizational units that deliver them. This mapping ensures that service offeringsare covered organizationally or identifies gaps.

Organizational Staffing

In addition to mapping services to organizations, we map roles required for delivery of services toorganizations. This is a prerequisite to staffing. While the organizational relationships arerecorded in the Organizational Structure diagram, the staffing of the organizations is recorded inthe 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. Inthe architecture we record expected costs for roles. Then knowing how many people are neededin 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 proposedcapability (to-be) enables the architect to determine the fit, gaps, costs, and benefits to thebusiness.

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 theprocesses in a hierarchical manner. These processes are descriptions about what the businessdoes to provide a service, and the process detail diagrams (Process Taxonomy diagram, ProcessContext and Performance diagram, and Process Information Flow diagram) describe how theseprocesses 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 ProcessTaxonomy diagram and the other process detail diagrams.

Process Context and Performance

The Process Context and Performance diagram provides the architect and the owner with anunderstanding of the scope, context, and performance of each process in the taxonomy. For eachprocess or activity of the process taxonomy, we describe the scope and context in the form ofinputs and outputs, the policies that constrain or govern the operation of the process, the systemsused to automate the process, and the roles and skills required to execute the process. Thediagram 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 ofbusiness rules associated with the processes and by training people performing the process. Thecosts are depicted as pie charts.

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




31/46

Public 04/07/09 24

Engineering Institute (SEI).25

If the processes being designed are dependent on processesoutside the scope of this capability, then the data being transferred between the processes mustbe well-defined and agreed to. Well-defined means that a UML or IDEF1X-based data modelexists, 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 ProcessTaxonomy diagram and shows the information flow between them. With the OV-5 family ofdiagrams, we are building up an understanding of the processes that are associated with theservices in the capability.

The idea here is to understand where data is coming from and where it is going to, and todemonstrate 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 rulescan include such guidance as the conditions under which operational control passes from oneentity 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 Detailsdiagram 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 thedata 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 isattached to the process steps that it governs.

Special business rules that are process related are referred to as internal controls. They too areattached 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-orderedexamination of the information exchanges between participating operational nodes as a result ofa 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 astriggers and outcomes of the process and the steps performed to get the business from trigger tooutcome. 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 Detailsdiagram states when it flows and why, and provides relevant details.

25Carnegie Mellon Software Engineering Institute, Capability Maturity Model Integration (CMMI)

Web Site, http://www.sei.cmu.edu/cmmi/




32/46

Public 04/07/09 25

The process models bring together much of the information gathered in other architecturediagrams for a comprehensive view of how activities are performed. They use the BusinessProcess 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 tasksData (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. Eachservice in the Capability Service Taxonomy is diagrammed with required courses listed. Thisdiagram also enables the architect to specify which roles require training. With this diagram, thearchitect can also inventory personnel assigned to existing roles and establish a record of whohas 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 businessobjects or entities and associated attributes. For each attribute the architect or engineer canspecify data type, length, and whether the field is required. At the domain level an authoritativesource is assigned in the form of an agency. Having a record of authoritative sources and datastewards 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 UMLmethod is typically referred to as an object modeling method and the IDEF1X is a relationshipmodeling method.

Data StateFor each class of data in the Data Model diagram, Data State diagrams can be created thatdocument the valid state changes that a particular class of data might go through. We use theUML for modeling state and ensure that all business events that trigger changes in state are alsoin 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 aSituational Awareness System because it is the business events that define a situation thatsomeone might be interested in knowing about. The system must know about the events, theinformation 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 DataState diagrams using the Extensible Markup Language. We do this to establish XML-based dataexchange standards between trading partners.

Systems Architecture Diagrams

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


33/46


34/46

Public 04/07/09 27

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 beaddressed, and policies that need to be established.

Sequence

The Sequence diagram provides a time-ordered examination of the data exchanged betweenparticipating external and internal systems, system functions, or human roles as a result of aparticular 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 supportingthe people using the systems. For example, if a service call is placed, the service desk can usethe Sequence diagrams for problem determination. The Sequence diagrams help the servicedesk 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 toimplement 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 listof products and protocol standards with names and descriptions. Since this is a simple list, onecan use a spreadsheet to gather and depict the information, but the list of products and standardsneeds 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.





35/46

Public 04/07/09 28

METHODSThis section defines the industry-standard methods that the City will apply in developingbusiness-process models, activity models, data models, and other architecture diagrams. Fivestandards 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 documentmodels38 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 fourrepresent 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 duringrequirements gathering), Activity Diagram, and State Machine Diagram.

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

39

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

Integrated Definition (IDEF) FamilyThe 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 Forceto integrate computers and manufacturing. Two methods are of particular interest in developingEnterprise Architecture: IDEF0 and IDEF1X.

The IDEF0 method was designed to model the decisions, actions, and activities of anorganization or system. The IDEF0 method was derived from a well-established graphicallanguage, the Structured Analysis and Design Technique (SADT). The United States Air Forcecommissioned the developers