Service Modeling Standards (doc)

595 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
595
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
14
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Service Modeling Standards (doc)

  1. 1. 1 Kent Andrus Office of Financial Management 2 3 Scott Came Department of Information Services4 5 Laura Parma Department of Information Services6 Enterprise Architecture Committee Steward7 8 9 10 11 12 13 14 15 Service Modeling Standards 16 17 ISB Standards 18 Version 5 19 20 November 9, 2006 Information Services Board Enterprise Architecture Committee Bill Kehoe, Department of Licensing Co-chair Cathy Munson, Legislative Service Center Co-Chair Department of Information Services 1110 Jefferson Street SE P.O. Box 42445 Olympia, WA 98504-2445 Phone 360/902.3519 Fax 360/902.2982 1
  2. 2. 2Washington Enterprise Architecture Program November 9, 2006 3Service Modeling Standards ISB Standards—Version 5 21 Table of Contents 221. Document History.......................................................................................................................3 232. Document Context......................................................................................................................3 243. Introduction and Purpose............................................................................................................4 25 3.1. Summary of Standards.........................................................................................................4 264. Compliance Component Information...........................................................................................4 27 4.1. Basic Component Metadata.................................................................................................5 28 4.2. Statutory Authority................................................................................................................5 29 4.3. Scope...................................................................................................................................5 30 4.4. Relationship to Other Components, Policies, Standards, or Guidelines...............................5 315. Service Modeling Standards and Rationale................................................................................5 32 5.1. Standards.............................................................................................................................5 33 5.1.1. Contextual Modeling Standards.....................................................................................5 34 5.1.2. Conceptual Modeling Standards....................................................................................6 35 5.1.3. Logical Modeling Standards...........................................................................................6 36 5.1.4. Physical Modeling Standards.........................................................................................8 37 5.1.5. Templates......................................................................................................................8 38 5.2. Rationale..............................................................................................................................8 39 5.2.1. Alignment with Over-Arching Enterprise Architecture Principles....................................8 40 5.2.2. Encouraging Reuse through Improved Communication and Common Tools................9 41 5.2.3. Conformance with Federal Standards for Information Exchange.................................10 426. References...............................................................................................................................10 43 Appendix A: Documenter Team...................................................................................................11 44 Appendix B: Review Log..............................................................................................................12 45 46 47 4 Page 2 of 12
  3. 3. 5Washington Enterprise Architecture Program November 9, 2006 6Service Modeling Standards ISB Standards—Version 5 48 49 1.Document History Date Version Editor Change April 14, 2006 1.0 Kent Andrus Initial Draft Scott Came May 12, 2006 1.1 Scott Came Initial guidelines, rough draft of rationale May 26, 2006 1.2 Scott Came Added definitions to scope statement; plain talk May 31, 2006 2.0 Scott Came Endorsed by EAC September 14, 2006 4.0 Trina Regan Adopted by ISB October 25, 2006 4.1 Trina Regan Guidelines to standards Endorsed by EAC November 9, 2006 5 Paul Douglas Adopted by ISB as Standards 50 51 2.Document Context 52This document currently has ISB Standards status. This status signifies that the document was 53adopted as standards by a vote of the Information Services Board. For more information about 54the ISB Enterprise Architecture Committee and its initiative, please visit the EA Committee 55website at: http://isb.wa.gov/committees/enterprise/Default.aspx. 7 Page 3 of 12
  4. 4. 8Washington Enterprise Architecture Program November 9, 2006 9Service Modeling Standards ISB Standards—Version 5 57 3.Introduction and Purpose 58This document provides standards to agency architects, developers, and system integrators 59regarding the modeling and description of services. 60The concept of a service is fundamental to the state’s overall approach to system integration, as 61defined in the Conceptual Integration Technical Reference Architecture ([TRA]†). A service is the 62way in which the provisioner of a capability (for example, an agency that owns and maintains an 63information system) makes that capability available to others. By making capabilities available 64through services, rather than making the capabilities directly available to others, agencies avoid 65introducing technical dependencies between systems that make them difficult to change. The 66[TRA] provides a complete definition and discussion of these concepts; the reader should 67interpret and understand the standards in this document within the context of the [TRA]. 68An architect, developer, or system integrator who wishes to use a service to access a capability 69must have a detailed description of the service. This description must include: 70 • A complete and detailed description of the effect of using the service; that is, what (in 71 business terms) can be accomplished by using the service to access the capability 72 • A description of the actions supported by the service (that is, how does the developer use 73 the service to accomplish the effect?) 74 • A definition of the information exchanged during interaction with the service 75The purpose of the standards in this document is to promote consistency in these descriptions 76across the state enterprise. The rationale section of the document below identifies the benefits 77expected to result from this consistency in documentation. 783.1.Summary of Standards 79This document contains the following standards for services provided and consumed among 80partners in the state enterprise: 81 • Each service should have a contextual description that establishes the name for the 82 service, provides a brief description of the service’s real-world effect, and indicates the 83 business processes in which the service participates 84 • Each service should have a conceptual description that fully describes the real-world 85 effect, lists the actions that can be performed on the service, and provides brief textual 86 descriptions of the principal information entities involved in consumers’ interaction with 87 the service 88 • Each service should have a logical description that fully defines, in implementation- 89 independent terms, the actions that can be performed on the service, including full 90 (complete and precise) definitions of the messages involved in consumers’ interaction 91 with the service 92 • Each service should have a physical description that aligns with the Service Interaction 93 Profiles supported by the service’s interfaces 94 4.Compliance Component Information 95This section documents key information required of all compliance components in the 96architecture. 10† Abbreviations formatted in this [style] represent citations defined in the References section 11below. 12 Page 4 of 12
  5. 5. 13Washington Enterprise Architecture Program November 9, 2006 14Service Modeling Standards ISB Standards—Version 5 974.1.Basic Component Metadata 98Component Identifier: Not yet assigned 99Adoption Date: Not yet determined 100Effective Date: Not yet determined 1014.2.Statutory Authority 102The provisions of RCW 43.105.041 detail the powers and duties of the Information Services 103Board (ISB), including the authority to develop statewide or interagency information services and 104technical policies, standards, and procedures. 1054.3.Scope 106These standards apply to executive and judicial branch agencies and educational institutions. 107Academic and research applications at institutions of higher education are exempted. 108In this document, the terms “state agency” and “agency” mean any agency or institution within the 109scope of the previous paragraph, and the term “state enterprise” means all agencies and 110institutions (collectively) within the scope of the previous paragraph. 111Starting November 9, 2006, the Integration Architecture Standards will govern the planning and 112construction of all applications that share data with other agencies. 113 114Exemption requests must be submitted to DIS MOSTD and will be forwarded to the ISB for 115decision. Applications existing or under construction as of November 9, 2006, are not required to 116immediately comply, but will be required to comply when redesigned or replaced. 1174.4.Relationship to Other Components, Policies, Standards, or Guidelines 118None. 119 5.Service Modeling Standards and Rationale 120This section documents the solution design standards and the rationale behind them. 1215.1.Standards 1225.1.1.Contextual Modeling Standards 123Each service must exist within the context of at least one business process; a service plays a 124specific role in accomplishing a business process that achieves demonstrable business value. 125The state must maintain a model of each business process that indicates the role played by each 126involved service. A future release of the statewide enterprise architecture will include standards 127or guidelines for business process models. This document assumes that these standards will, at 128a minimum, indicate that business process models clearly indicate the role particular services 129play in each business process. 130The description of each service should include a list of the business process models in which the 131service plays a role. This list may be maintained manually, or may be generated out of 132information in the state’s service repository (as described in [TRA].) 15 Page 5 of 12
  6. 6. 16Washington Enterprise Architecture Program November 9, 2006 17Service Modeling Standards ISB Standards—Version 5 133The description of each service should include a contextual summary that establishes the name 134of the service and a brief (single paragraph) description of the real-world effect of using the 135service 1365.1.1.1. Service Naming Standards 137The name of the servicemust encapsulate the essential aspects of the real-world effect of the 138service; that is, the name of the service must represent what the service accomplishes (in 139business terms), rather than how the service works. In particular, the name shall not indicate the 140underlying information system that implements the service, nor the agency or organization that 141provisions the service, nor any technical details about how the implementation works. 1425.1.2.Conceptual Modeling Standards 143The description of each servicemust contain a conceptual view that contains the following: 144 • A complete description of the real-world effect of the service (that is, what the service 145 accomplishes) 146 • A list and brief (single paragraph) description of each of the actions that can be 147 performed on the service 148 • A list and brief (single paragraph) description of the principal information entities involved 149 in interaction with the service via its actions 150 • A list of the principal metadata categories and values for the service (a future version of 151 these standards or related guidelines may specify a standard set of metadata categories 152 for services, based on experience implementing the integration architecture) 153All aspects of the conceptual description must be free of any implementation details or 154dependencies. The description shall not refer to particular databases or systems in the 155description of the real-world effect; rather, the description must describe the business effects of 156the service. 1575.1.3.Logical Modeling Standards 158The description of each service must contain a logical view that consists of a Unified Modeling 159Language (UML) version 2.0 static structure (class) model. This model must contain: 160 • A UML interface that represents the service 161 • A method on the interface for each action that can be performed on the service 162 • A signature for each method on the interface that identifies input and output messages 163 associated with the action 164 • A class or classes representing the components of each message 165 • Attributes on each class and associations between classes representing the structure of 166 each message 167Each interface, class, method, attribute, and association must have a complete definition that 168captures its semantic meaning. Each attribute must identify its data type and other parameters 169that specify the range of its values. 170Each interface, class, method, attribute, and association must have a set of metadata categories 171and values, as appropriate, to define the context of the element. A future version of these 172standards or related guidelines may specify a standard set of metadata categories for services, 173based on experience implementing the integration architecture. At a minimum, the metadata for 174a service and for each message must include the agencies that own and govern the structure of 175the service and messages and the current version of the service and messages. 18 Page 6 of 12
  7. 7. 19Washington Enterprise Architecture Program November 9, 2006 20Service Modeling Standards ISB Standards—Version 5 176The name of each interface, class, method, attribute, and association must encapsulate the 177meaning of the element in a way free of any reference to implementation detail. Each class and 178interface must include an identifier in its metadata. 179Models of messages must leverage concepts, structures, and semantics from relevant industry- 180standard models and vocabularies whenever those models and vocabularies cover the content of 181the messages. That is, message models shall not re-invent content that has already been 182defined in industry-standard models and vocabularies. Over time, the information architecture 183within the statewide enterprise architecture will identify industry-standard models and 184vocabularies to guide the modeling of messages. 1855.1.3.1. Conformance to the Federal Enterprise Architecture Data Reference Model 186The standards in this section conform to the guidance of the Federal Enterprise Architecture Data 187Reference Model ([FEA DRM])† with respect to the modeling of information exchanged between 188systems. 189The following table aligns modeling artifacts with concepts in the Data Description standardization 190area ([FEA DRM] chapter 3): DRM Concept DRM Attribute DRM Description Modeling Artifact(s) Entity Identifier A unique string associated with an UML 2.0 Class identifier Entity for identification purposes metadata Name Name of an entity UML 2.0 Class name Description Description of an entity UML 2.0 Class description / definition (as a comment) Data Type Name Name of a data type UML 2.0 DataType Description Description of a data type UML 2.0 DataType description (as a comment) Attribute Name Name of an attribute UML 2.0 Property name Description Description of an attribute UML 2.0 Property description (as a comment) 21† The FEA DRM is one of the reference models in the Federal Enterprise Architecture. It is a set 22of standards to guide the definition of enterprise architectures in individual Federal agencies. It 23defines a set of concepts that each agency’s architecture must address, in the area of information 24architecture and data exchange. 25 Page 7 of 12
  8. 8. 26Washington Enterprise Architecture Program November 9, 2006 27Service Modeling Standards ISB Standards—Version 5 Relationship Name Name of a relationship UML 2.0 Association name Description Description of a relationship UML 2.0 Association description (as a comment) 191The ability to define metadata for service and message models and their contents conforms to the 192general guidance of the Data Context standardization area ([FEA DRM] chapter 4). The model of 193a message conforms to the concept of an Information Exchange Package as defined in the Data 194Sharing standardization area ([FEA DRM] chapter 5). 1955.1.4.Physical Modeling Standards 196These standards do not address the physical modeling of services. A service’s physical model is 197equivalent to the specification of its interfaces. Standards for the structure, form, and content of 198service interfaces are documented in Service Interaction Profiles, as defined in the [TRA], in 199particular the profile’s satisfaction of Interface Description Requirements and Message Definition 200Mechanisms. 2015.1.5.Templates 202The Enterprise Architecture Program expects to develop templates for the contextual, conceptual, 203and logical views of a service’s models in the near future. These templates will support and 204conform to these standards. 2055.2.Rationale 206The rationale for these standards is that they: 207 • Align system integration efforts with three of the over-arching enterprise architecture 208 principles adopted by the Information Services Board 209 • Encourage reuse of common, shared service interfaces through improved communication 210 • Position the state enterprise to adopt common tools for modeling of information 211 exchanged between systems and agencies 212 • Conform to Federal information exchange modeling guidelines 2135.2.1.Alignment with Over-Arching Enterprise Architecture Principles 214This section demonstrates how these standards align system integration efforts with three over- 215arching enterprise architecture principles adopted by the Information Services Board: 216Interoperability, External Linkages, and Business Ownership. 2175.2.1.1. Alignment with Interoperability Principle 218The Interoperability Principle states that interoperability is necessary to support the view of state 219government as a single enterprise and to enable the consolidation of similar functions across 220agencies. Interoperability also facilitates the sharing of information, both within state government 221and with external partners. The automated sharing of information can streamline business 222processes, which improves service and reduces costs. 223These standards promote interoperability by defining common techniques for the modeling of 224system interfaces (services). Without these common techniques, tools used to model interfaces 225will not interoperate—or, conversely, the state enterprise will not be positioned to define 28 Page 8 of 12
  9. 9. 29Washington Enterprise Architecture Program November 9, 2006 30Service Modeling Standards ISB Standards—Version 5 226requirements that lead to interoperability of modeling tools. In particular, the identification of 227Unified Modeling Language (UML) as the basis for logical modeling of service interfaces and 228messages aligns interface documentation with an established industry standard that has been 229implemented in a large number of off-the-shelf modeling tools. 230These standards also promote interoperability of systems by encouraging clear and precise 231documentation of system interfaces. This documentation can be used in system procurements 232and designs to ensure that new systems interoperate with existing systems. 2335.2.1.2. Alignment with External Linkages Principle 234The External Linkages Principle states that the state enterprise should facilitate linkages with 235external partners, such as local and Federal government and private sector organizations. The 236rationale for this principle is that these linkages can improve services to citizens and businesses, 237and can streamline business processes that cross levels of government or include the private 238sector. The principle identifies three implications that are relevant to these standards: 239 • External linkages may require migration to open industry standards 240 • External linkages may require enterprise-level metadata 241 • Systems should be constructed with clearly defined interfaces 242These standards address all three of these implications. 243The adoption of Unified Modeling Language (UML) as the standard for logical description of 244interfaces and messages establishes an industry standard for interface description. This will 245improve the ability for external partners to understand what they need to do in order to interact 246with state government systems. It is also more likely that external partners will define their 247interfaces in terms of open standard notation rather than proprietary notation. By adopting open 248standards like UML, the state enterprise will align its modeling practices with the likely practices 249of its partners. 250These standards establish an initial core of enterprise metadata for services and messages, and 251set an expectation for managing metadata at the enterprise level. Initially, the metadata consist 252of a description of the service’s real-world effect, the owner agencies, and versioning information. 253These standards promote the clear definition of interfaces between systems. 2545.2.1.3. Alignment with Business Ownership Principle 255The Business Ownership Principle states that enterprise technology assets, such as system 256interfaces, should have a clear business owner. The rationale for this principle is based on 257change management, in that an understanding of who owns an asset helps to ensure that those 258most affected by a change to the asset are involved in the management of the change. 259By promoting the clear and precise description of system interfaces (services) in a standard way, 260and by identifying owning agencies for each interface and message, these standards support the 261management of changes to interfaces and messages. The contextual description of a service 262includes all of the business processes (integration scenarios) that involve the service, which 263assists in identifying stakeholders who should be involved in the management of changes to 264service interfaces. 2655.2.2.Encouraging Reuse through Improved Communication and Common Tools 266Reuse of system interfaces (services) is a key factor in the reduction of the costs and risks of 267information technology projects. For project decision-makers to reuse services, they need to 268know that those services exist, what the services do, and how to interact with the services. The 269conceptual integration architecture defined in [TRA] recognizes these information needs in the 270concepts of visibility and awareness. 31 Page 9 of 12
  10. 10. 32Washington Enterprise Architecture Program November 9, 2006 33Service Modeling Standards ISB Standards—Version 5 271These standards support reuse by encouraging service descriptions that: 272 • Define clearly what a service does 273 • Define clearly the messages involved in the information exchange between systems via 274 the service 275 • Define metadata used to discover the service 276 • Use a standard notation that reduces ambiguity and improves common understanding of 277 the structure and semantics of service interfaces and messages 278These standards also improve communication by establishing a single modeling notation as a 279common language for discussion of integration requirements. This will allow the state enterprise 280to economize on training and modeling tools, and will improve the efficiency and effectiveness of 281multi-agency project teams. It will improve the ability for vendors to participate on multiple 282projects without having to learn a new approach and new standards on each. 2835.2.3.Conformance with Federal Standards for Information Exchange 284As demonstrated in section 5.1.3.1 above, these standards conform to the relevant aspects of the 285Federal Enterprise Architecture Data Reference Model (FEA DRM). 286Alignment with the FEA DRM results in the following benefits: 287 • Improved alignment with Federal government partners that fund state government 288 programs and initiatives, especially those that involve system integration with the Federal 289 government 290 • Improved communication with vendors, who will be increasingly aware of FEA concepts 291 through engagements with the Federal government and other states that have adopted 292 the FEA 293 • Increased stakeholder confidence in the viability of the state’s integration architecture and 294 modeling standards, through alignment with an accepted model endorsed by the Federal 295 government 296 6.References 297FEA DRM United States Office of Management and Budget, 298 Federal Enterprise Architecture Program (2005). Data 299 Reference Model, version 2.0. 300TRA Washington State Information Services Board, 301 Enterprise Architecture Committee (2006). Conceptual 302 Integration Technical Reference Architecture, Enterprise 303 Architecture Committee Document. 34 Page 10 of 12
  11. 11. 35Washington Enterprise Architecture Program November 9, 2006 36Service Modeling Standards ISB Standards—Version 5 304 Appendix A: Documenter Team 305This document was developed through the Integration Architecture enterprise architecture 306initiative, chartered December 14, 2005. The following individuals were members of the 307Documenter Team for this initiative, and participated in review of this document. 308 • Kent Andrus, Office of Financial Management 309 • Lori Bame, LEAP Committee 310 • Jerry Britcher, Department of Social and Health Services 311 • Scott Came, Department of Information Services 312 • Gary Dubuque, Department of Revenue 313 • Jim Eby, Department of Fish and Wildlife 314 • Brian Everson, Washington State Patrol 315 • Laura Graham, Legislative Service Center 316 • Robin Griggs, Department of Licensing 317 • John Hanson, Commission on Trade and Economic Development 318 • Tom Henderson, Department of Labor & Industries 319 • Paul Hubert, Department of Information Services 320 • Debbie Johnson, The Higher Education Coordinating Board 321 • Lorraine Louderback, Department of Corrections 322 • Dan Mercer, Department of Labor & Industries 323 • Miles Neale, Department of Ecology 324 • Bill Norris, Department of Health 325 • Laura Parma, Department of Information Services 326 • Mike Rohrbach, Administrative Office of the Courts 327 • Jeff Sharp, Office of the State Treasurer 328 • Matt Stevens, Department of Information Services 329 • Lyle Tillett, Department of Retirement Systems 37 Page 11 of 12
  12. 12. 38Washington Enterprise Architecture Program November 9, 2006 39Service Modeling Standards ISB Standards—Version 5 330 Appendix B: Review Log 331The following feedback on this document was received by the Enterprise Architecture Program; 332the response to each contribution is noted below. Review by whom Contribution Response and when ISB • Adopted as Guidelines Adopted and posted as Guidelines September 14, 2006 EA Committee • Added Grandfather language to Endorsed as Standards October 25, 2006 Scope section • Changed Guidelines to Standards 333 40 Page 12 of 12

×