|
Object-Oriented Techniques for Managing Enterprise Transition by Rob Byrd and Earl Pedersen Table of Contents The Case for Object-Oriented UML Enterprise Architecture Unique Aspects of Serco’s Approach Developing an Object-Oriented Enterprise Architecture Download PDF Version: EACapability.pdf Download EA Media Presentation IntroductionSerco is an award-winning leader in the application of object-oriented analysis and design (OOAD) for the practice of Enterprise Architecture (EA). Our Unified Modeling Language (UML) based method, Net-Centric Enterprise Architecture, uses an object-oriented approach to define and model target enterprise operational processes – facilitating transition planning to a service-oriented architecture (SOA). Our professional services include a repeatable technique to capture mission requirements in context of operational use (Requirements Understanding); to discover common, extendable and reusable processes (Integrated Enterprise); and to assist in the implementation of target capabilities via a well-managed spiral model (Managed Change). Our EA Center of Excellence in Colorado Springs is a showcase of state of the art architecture development facilities designed specifically for enterprise model development. Finally, we’re experts in the art of collaboration to assist enterprise leadership in achieving the service-oriented perspective.
A service-oriented architecture (SOA) is a description of the structure of heterogeneous systems in terms of their components and the services they provide, without regard for the underlying implementation of these components, services and connections between components. A SOA approach provides loose couplings with the operating systems and programming languages underlying the applications.[1] SOA separates functions into distinct units (services) distributed over a network, which can be combined and reused to create new business applications.[2] These services communicate with each other by passing data from one service to another, or by coordinating an activity between two or more services with a specific desired outcome. Our object-oriented (OO) approach leads to the production of highly integrated, agile, and affordable systems, fielded in a shorter amount of time compared to the traditional structured analysis approach. We determined after much research that Unified Modeling Language (UML) business models used to manage functional requirements are easier to understand by business analysts and ultimately the developers tasked to build the systems. As the software development industry is acutely aware, the significant power of an object-oriented approach is the ability to identify reusable elements within and among enterprises using a service-oriented architecture approach to include: ü Processes (operational or business activities) ü System components such as enterprise workstations and servers ü Interfaces such as those between internal and external data sources ü Nodes taking into account organizational considerations ü Architectural concepts such as information exchanges The power of reuse and service-orientation can, if properly exploited, reduce development costs, schedule, and risks, while facilitating integration and interoperability. We have continuously matured our method since 1997 and now have more than 35 certified and practicing architects working for our Colorado Springs Enterprise Architecture Center of Excellence. We leverage our Enterprise Architecture Center of Excellence, described later in this paper, in every Business Process Reengineering (BPR) and EA engagement we perform. This paper provides an overview of our EA practice and demonstrates how enterprise architectures can assist SOA transition efforts. BackgroundIn 1997, Serco was providing system engineering and technical assistance (SETA) for the development of the Combatant Commanders Integrated Command and Control (C2) System (CCIC2S) program. The command and control capability supporting Air Force Space Command (AFSPC), North American Aerospace Defense Command (NORAD) and U.S. Strategic Command (USSTRATCOM) and their components required an integrated, interoperable, flexible, and cost effective capability that enabled warfighters to accomplish both their current and evolving missions as well as evolving Department of Defense (DoD) guidance for C2 systems. The CCIC2S vision was to provide these C2 capabilities and guidance in an integrated environment that enabled authorized users to access relevant air, space, missile, and intelligence mission information, and to share that information with other authorized users, worldwide. Previous approaches to system development for AFSPC, NORAD and USSTRATCOM C2 utilized an operational architecture construct built along mission threads with emphases on process. As a result, common capabilities and integrated solutions were not part of the fielded systems. Instead, stove piped solutions consisting of 34 separate operational systems and 27 different programming languages emerged supporting specific functionality within a given mission (i.e., space, air, missile, etc.). Maintaining the hardware and software supporting this architecture was very costly – it did not accommodate change nor did it promote collaboration among the growing community of users. Moreover, there was no operational architecture baseline to support the constructs in what was then known as the DoD Command, Control, Communications, Computers, Intelligence, Surveillance, and Reconnaissance (C4ISR) Architecture Framework (CAF) depicting warfighter capabilities to implement the CCIC2S vision. As a result, the initial stages of the CCIC2S program focused on identifying the baseline operational functions, redundancies, and describing a vision for migrating current systems. The dilemma was in finding a method to enable examination of the operational activities across mission areas to identify functional redundancies within each stove-piped process or activity. To meet this challenge, we identified common joint and Service C2 functions from doctrine as the foundation of operational functions. We used the traditional Integrated Definition (IDEF) approach to explore the common aspects of command and control and the method worked very well. However, we discovered that our Core C2 model was not adaptable or extendable to describe the Air, Space, and Missile mission behavior [the observable effects of an operation or event, including its results]. With this challenge, we determined that an object-oriented operational architecture approach was necessary to integrate common functions across multiple mission areas. With the assistance of operational subject matter experts using our object-oriented approach, we identified system redundancies, common capabilities, and mission-unique capabilities within the existing mission operations. This approach proved to be very successful. As shown in the Figure 2, operational activities were streamlined from 371 to 81 C2 activities and grouped in four high level C2 areas (C2 operational patterns). The Monitor-Assess-Plan-Execute (MAPE) pattern has since become the C2 standard while laying a foundation for an extendable, adaptable, and reusable UML Use Case library supporting multiple mission threads. In subsequent years, the architecture evolved to provide SOA solutions supporting network and Web-based deployments that integrated information exchanges across enterprise boundaries. Dr. Alex Levis (Chief Scientist of the Air Force) recognized the significance of our approach when he quoted the CCIC2S architecture as one of the top three architectures in the Air Force. Some may disagree; however, we determined that object-oriented methods provide true vertical and horizontal integration. Structured techniques such as IDEF only provide vertical integration (decomposition). Finally, we learned the value of the UML as an engineering language to increase communications with engineers and stakeholders; whereas, IDEF is a method lacking a language.
Figure 2 – CCIC2S Transition Leveraged BPR and Object-Oriented UML Methods We determined an approach to evolve from a structured
analysis modeling method The Case for Object-Oriented UML Enterprise ArchitectureThe UML is an industry standard for the creation of visual models that represent behavior of business systems for object-oriented software development. It combines the best diagramming practices applied by software developers over the past 40 years. The Object Management Group (OMG) formalized the notation in 1997 and the DoD community is formalizing a common UML method through OMG’s UML Profile for DoDAF and MODAF (UPDM). The UPDM standardizes a common UML profile to ensure consistency of method and architecture data elements throughout the defense enterprise. The UML is not a computer software language such as Java, C++ among others; rather, the UML is a visual language using semantically rich, graphical and textual design notations to capture information technology conceptual designs. A notation, such as UML, allows raising the level of abstraction, while maintaining rigorous syntax and semantics. In this way, it improves communication among conceptual teams as the design evolves and the community reaches agreement. The language allows the reader to reason about the design, and it provides an unambiguous basis for implementation. A model, therefore, represents an understandable view of a system. It shows the essentials of the system from a particular perspective and hides the non-essential details. Models can help in the following ways:[3] ü Aiding understanding of complex systems ü Exploring and comparing design alternatives at a lower cost ü Forming a service-oriented foundation for implementation ü Capturing functional requirements precisely ü Communicating decisions unambiguously Because of the UML’s popularity and success, industry largely moved away from structured analysis and functional decomposition methods – proven less capable of handling the complexity of modern information systems.[4] Today, OO solutions drive network and Web-based system deployments, so the application of UML at an enterprise level - especially when planning a transition to SOA - is a natural evolution of the same type of thinking, with the same expected benefits. In fact, this paper highlights the analogy between OOAD for software development purposes and OOAD for EA purposes. The use of UML for EA provides several distinct advantages: ü Provides architects with abstraction techniques such as patterns, information hiding, and adaptation that are useful in addressing complexity ü Allows adaptation of a common service to accommodate mission specific needs ü Increases flexibility to accommodate mission and requirements changes ü Reduces cost and risk through modeling rather than real world experimentation and early implementation ü Provides a common language among architects and developers to improve communication, reducing translation problems and providing a basis for CONOPS-to-code traceability ü Provides planning in context: gap identification, project definition, sequence planning, and portfolio management The following paragraphs discuss these significant advantages in more detail. Reduced Complexity – Object-orientation is exactly what it implies – orientation toward the object rather than functional decomposition, which is oriented toward decomposition of functions. Objects are abstractions – a way of describing the real world by addressing the information about the object that is important to your purpose or the problem you are trying to solve. Thus, the OO modeling notations provide the architect a way of modeling important requirements while hiding unnecessary information (such as implementation details) that can unnecessarily complicate the higher-level problems under investigation. UML diagrams provide a foundation that allows architects to focus on differing perspectives of the solution, and UML packages provide additional flexibility to segment (package) portions of the overall solution – these packages allow visionary teams to group implementations by contracts (agreements between stakeholders) while maintaining the integrity of the architecture’s desired effect. These capabilities provide integration of proven architectural and domain patterns (proven best practice) and the segmentation of new development from existing library assets (stored in packages). The C2 (MAPE) pattern described earlier is an example of a domain pattern extendable for many mission domains. The constraining core patterns enforce consistency of process and the underlying core data classes are adaptable for specialized needs. Adaptation and Flexibility - Serco’s early innovation with UML was to create UML Use Cases abstracted at the enterprise level rather than software coding level. Initially we used this approach to model common C2 functions built once and reused (extended or adapted) many times to reducing system support costs. As messaging technologies and service-oriented architectures became prevalent we realized our enterprise level use cases were descriptions of service behaviors accessible across a network and reusable in many different ways – achieving the differing effects or results of value. Just as developers were able to maintain reusable software components in a class library to provide a system level service, we maintain reusable use cases in a repository of mission level services. Thus, our robust repository of C2 use cases provide agility to create new mission threads more efficiently – clients who have mapped systems and software to these use cases can deploy these service components in novel ways across the network by understanding the object (instance of a class) it consumes and the object it produces. Similarly, we are helping clients in other mission areas define enterprise use cases and build repositories specific to their missions so they too can perform the logical and physical realization (software and systems) that are intrinsic to SOA migration. Essentially, the architecture is the basis for portfolio management of the developmental activity. Cost and Risk Reduction – OOAD goes hand-in-hand with other modern software development best practices - visual modeling, iterative development and risk-driven development, among others.[5] These techniques target the well-known “IKIWISI” phenomenon in software development – the user who can’t quite describe their requirement, except that “I’ll know it when I see it.” This tongue-in-cheek acronym describes a very serious risk to projects - lengthy requirements evolution and meticulous software development, but when end users try the final product, they find they really wanted something different. Discovering this disconnect late in the effort, after significant design concepts have been locked in, after significant cost has been expended, and after significant schedule has passed can often be fatal to a project. We believe the solution includes the development of UML Use Cases to place requirements in context; visually modeled to better communicate requirements; iterative and incremental development to capture early user feedback; and early rather than late introduction of high risk areas to accommodate change prior to significant cost and schedule consumption. These concepts also apply to EA where (1) use cases present enterprise functional requirements in mission context; (2) modeling elicits and verifies mission requirements; (3) the logical and physical realization of the most frequently used service components can be prioritized into spiral deliveries; and (4) low-cost incremental capability models can be developed prior to the expenditure of funds and schedule on costly enterprise migrations or readiness exercises. Common Language and Method – UML is an industry standard with more than 10 years of successful use. Its popularity has grown with OO development and Web technologies. Today, all computer science graduates learn the UML; staging the notation as a tremendous tool to communicate requirements between architects and developers. One of the compelling reasons for using the UML to describe an enterprise is the idea of leveraging the common notation to describe requirements from Concept of Operations (CONOPS) to code, providing traceability from mission requirements to the servers and software modules that implement the needed services. Serco continues to collaborate with the MITRE Corporation, the OMG, and others to demonstrate this idea. Using one of our architectures that identified mission capability gaps, MITRE developed the code to close the gaps using our UML models – their work also used a UML framework. This “CONOPS-to-code” capability, a long coveted goal of EA, means mission executives can conceive new strategies and approaches with startling agility and deliver software faster and at lower expense. Despite its popularity with the technical community, UML is a bit abstract for presentation to mission personnel and executives; therefore, Serco developed a technique to use UML models to drive two-dimensional (2D) mission animations to improve understanding of the architecture with decision makers. We’ll discuss this approach later in this paper. Transition Planning – During software development, coders logically package elements of the architecture into subsystems or logical components targeted at providing similar functionality, and those subsystems or logical components are mapped to platforms that realize performance, availability, fault tolerance, scalability and other non-functional requirements. At the enterprise level, after modeling a representative number of target mission threads and use cases to the stakeholders’ satisfaction, this same process of logical and physical realization can begin. However, at the EA level of abstraction we focus on understanding how adequately current IT resources fulfill the use case requirements. At this stage of the architecture, Class Diagrams capture required services and assist in identification of gaps in capability. Packaged in logical groups, the use cases provide a contextual understanding to determine solutions via (1) existing IT resources, or (2) new projects targeted at closing the gaps. Where existing IT resources fulfill required services, UML Deployment Diagrams capture applications and servers providing a mapping (trace) to the physical platform. Our process provides the architectural foundation to close capability gaps through well-defined prioritizations, schedule, and cost into portfolios achieving the enterprise’s objectives. Sequenced over multiple budget cycles, well-defined capability gaps compete better in any given year for limited funds. Before commissioning actual projects, priorities must be set each year through a formal Capital Planning and Investment Control process. All government agencies have this process – for example, the DoD uses the Planning, Programming, Budgeting and Execution (PPBE) system. Figure 3 shows how EA fits into an Enterprise Management Model where the ability to provide “CONOPS-to-code” has real-world management significance.
Figure 3 – Architecture’s Role in Enterprise Management For complex systems, we’ve mastered the process and
method to use UML architectures *SWOT - Strengths, Weaknesses, Opportunities and Threats CPIC - Capital Planning and Investment Control Unique Aspects of Serco’s ApproachSerco is an industry leader in the development of business and system models using the UML. The Object Management Group as well as industry leaders such as IBM Rational (including founders of the UML) regularly seek our business modeling expertise and we frequently share our best practice methods with our industry partners. Specifically, we’re consulting with the UML Profile for DoD and Ministry of Defense Architecture Framework (UPDM) to develop a standard profile to analyze complex DoD problems to evolve future systems. Through our Enterprise Architecture Center of Excellence in Colorado Springs, we’re successfully using UML models to analyze complex problems for Army Training and Doctrine Command (TRADOC), Homeland Air and Cruise Missile Defense (HACMD), Global War on Terror, Joint Functional Component Command for Space (JFCC SPACE) Mission Operations (JSMO), North American Aerospace Defense Command (NORAD) C2, and many others. Our success is evidence – the Boeing Corporation awarded Serco the prestigious Technology Provider of the Year in 2007 for our UML business models describing network-centric operations for their integrated defense systems. In years past, we explored alternative modeling techniques such as Integrated Definition (IDEF) and Business Process Modeling Notation (BPMN) and others. We determined that the UML provides a more robust framework to analyze enterprise processes and supporting systems while laying a foundation to discover and identify critical elements to evolve the enterprise, improve efficiency and reduce operating cost. Serco’s approach emphasizes the use of standards, not tools. Our architecture procedures ensure integration across multiple teams – some key elements include: ü Based on industry standard UML to ensure effective communication with development personnel ü Employ collaboration tools and architecture laboratories to elicit subject matter expert requirements ü Examine the binding of use cases and service components to identify common functions and capabilities ü Utilize validation and verification tools to ensure use case integration across multiple mission threads ü Ensure stakeholder buy-in of using architecture-driven mission animation tools ü Manage the configuration of the model repository ü Promote the value of reuse to program managers Some notable differentiators include: Enterprise Architecture Center of Excellence - Our Colorado Springs Enterprise Architecture Center of Excellence (COE) provides an environment where we concentrate our expertise and centralize support to architecture and BPR efforts wherever our clients may be located. Building a UML modeling team with the necessary skills and resources from scratch in a new location can take as long as one to two years depending on the availability of a skilled staff. Serco is exceptionally successful at retaining quality people. Our staff includes many Senior Principal and Principal Enterprise Architects with OMG UML Professional Certifications practicing the object-oriented trade in excess of eight years. Our architecture staff currently consists of 35 trained and experienced object-oriented UML professionals, the largest concentration of UML enterprise expertise in the country! Implementing an architecture project using Serco’s EA Center of Excellence in Colorado Springs shortens ramp-up time significantly. In essence, our experienced staff begins work from day one using our existing architecture expertise and infrastructures – reducing the time required to train and mentor a capable staff. Finally, we’ve learned how to train less experienced client site Operational Analysts with minimal architecture skills to provide the necessary operational analysis and deliver preliminary products to our EA Center of Excellence for base lining, configuration management, and application of our architectural discipline.
Architecture Laboratories – Because architecture is very collaborative, we emphasize facility considerations. To be successful in developing use cases, architects collaborate and mentor in architecture laboratories properly equipped with large visual displays, computers, and controlled data access points. The large displays are necessary to observe all views of the use case and the many data sources (CONOPS, documents, and other information sources etc.) sometimes used to understand the required behavior (i.e., use case description) being modeled. Our architecture environment allows architects, subject matter experts, and stakeholders to collaborate on the architecture and agree on the optimal solution. We hesitate to consider these architecture laboratories optional – they are so productive that we built six laboratories and they’re in regular use today. If an architecture capability is required at your site, we can reduce the risk and shorten the time by exploiting our Colorado Springs capabilities while simultaneously instituting a local architecture capability. We successfully employed this option at Army Training and Doctrine Command (TRADOC) at Fort Monroe, VA. We can also supplement large, in-person sessions with Web-based conferencing. We are currently building a demonstration center in our Reston, VA that elicits client feedback on interim products. Training - We prepare our clients by providing an extensive two-week training program or an executive level overview, which includes hands on use of tools. During our training, the student learns the UML, our tools and methods, and as a group, students actually create a use case from scratch. Our training program teaches the student to think object-oriented by describing the process of collecting architecture requirements from an interface perspective. Tools and Repositories – We continuously conduct research on various UML modeling tools and share this information with clients at no cost. We have extensive experience building enterprise repositories, managing their configuration, and delivering their contents to clients via the Web and/or CD. We can offer the use of our labs to save schedule and client investment cost; however, after extensive UML tooling research, we deployed IBM Rational Software Modeler in our Architecture Centers of Excellence. The most significant strength of IBM Rational tools is their popularity within industry. Because IBM includes founders of the UML (then Rational), their tool provides a proper object-oriented implementation (another significant attribute). IBM still provides UML leadership today through the Object Management Group (OMG). In addition, Serco has a strong partnership with IBM Rational; IBM recognizes our technical leadership in object-oriented enterprise modeling and regularly collaborates with us on tooling considerations. The use of UML stereotypes (i.e., symbols, relationships, etc.) does not necessarily mean the underlying tool storage mechanisms are object-oriented. Scalability is important – this is particularly true if you’re modeling complex enterprises or you intend for your business models to go to code. Business models built using RSM are importable into Rational Software Architect (RSA) a UML tool that provides code generation. This approach allows the business model to evolve simultaneously with the implementation system model with no data concordance issues. This approach provides full traceability from CONOPS to code laying the foundation for UML models as a portfolio management and decision making mechanism. Finally, good configuration control is required to ensure large teams don’t interfere with each other’s work. We employ successful configuration management techniques to allow large architecture teams to unify successfully into a single model. We employ the open source Subversion to manage the configuration of our IBM Rational files. Because of these investments, we can eliminate license costs as a client consideration. We already provide the appropriate tools, laboratories, and agreements with IBM; clients need not accrue additional license costs unless they require native tool capability as well. Our modelers can simply set up client repositories in our Center of Excellence and access our tool suite there or remotely. By using our Center of Excellence you can entirely avoid or at least buy the schedule necessary to deal with the concerns that typically plague government laboratory build-outs, e.g. - software license costs and facilities considerations. Our modelers can work from Serco Offices, but we can still provide web conferencing capabilities throughout the country to review the results of our effort. Architecture Verification - Having standardized on the IBM Rational platform, we built specialized plug-ins to our toolset providing capabilities found nowhere else in the industry! Our enterprise mission threads link UML Use Cases to achieve an end-to-end business process. Even with standard operating procedures in place, there is no guarantee the entire mission thread (with use cases developed by differing teams) will execute properly. To resolve this problem, we first determined that object flow was essential for use case integration; then we built a verification tool that checks object flow within and between use cases through any definable mission thread. In the Rational tool, the observer actually sees an animation of objects moving from one use case activity to another. If the animation stops, we know we have a problem and more importantly, we know where to focus our corrective actions. This tool greatly reduces architectural risk and portfolio development risk. Architecture Validation – Another significant Serco innovation is the development of a UML tool plug-in that creates 2D animations actually driven by the architecture. This validation tool plug-in allows us to depict visually the mission thread in a context that users and mission executives can understand. We use these visualizations to demonstrate deployment of military resources on world maps; portray network information exchanges; and to animate business processes both within the office and beyond the enterprise boundary. Our technique engages stakeholders because they see and understand the model we are developing; providing participation and buy-in to the requirements development process. We continue this validation approach iteratively until the mission animation runs exactly as the stakeholders want it – often this facilitates agreement among stakeholders. We also save the 2D animations to Windows Media Files, complete with voice over, so our clients have products to perform organizational change management and training. Using our integrated architecture, we data mine our UML models to extract information to create important documentation communicating progress, areas of emphasis, development of functional requirements, as well as planning and acquisition documentation. Figure 5 shows a PC screenshot during the execution of such an animation, where a UML model (left screen shot) of an electronic purchase order system (e-PO) is driving a 2D animation (right screen shot) of interactions across enterprise boundaries and throughout a large metropolitan area. At the depicted moment, the e-PO system on the left of the 2D screen has released three Requests for Quote to vendors on the right side of the 2D screen. It is typical to portray the interfaces between platforms, systems and various roles during animation. We project a side-by-side presentation of the UML model and the 2D animation on adjacent large LCD displays in our COE laboratories to facilitate increased collaboration.
Figure 5 – Example Screen Shots from a 2D Animation Serco recognized the importance of vetting complex
architectures with leadership. Developing an Object-Oriented Enterprise ArchitectureTraditional EA engagements stress the use of frameworks to help planners deal with complexity. The most widely used is the Zachman Framework,[6] a matrix where columns representing data, function, network (location), people, time and motivation were the essential “abstractions” defining an enterprise and analyzed in successive levels of detail through contextual, conceptual, logical, physical and out-of-context rows, or “perspectives.” This prompted many practitioners to attempt to populate each cell of the 6 x 5 matrix with an artifact that purportedly described each abstraction at each perspective, for both the current architecture and their target architecture. Aside from the enormous effort and lengthy schedule required to collect and categorize this information, artifacts were often created that did not relate well to the cells above or below it, and the complex relationships between cells on the horizontal rows of the framework were frequently missed entirely. In addition, most methodologies in the 1980’s stressed functional decomposition as a starting point for the analysis, which often led to the development of redundancies across the enterprise. Various methodologies attempted to address these complexities throughout the 1990’s but they all primarily consisted of manual procedures to arrive at high-level approximations of enterprise requirements. With the advent of the UML standard and modeling tools that (1) help safeguard against redundancy, and (2) maintain relationships across Zachman’s perspectives and abstractions even as changes occur, our 21st century approaches to architecture are much more direct and flexible, and we can produce more detailed architectural products in a shorter timeframe. As with all architectural efforts facilitating transition, Serco’s approach is concerned with the current architecture, the target architecture, and the actions necessary to migrate from the former to the latter. However, we do not subscribe to the idea to model every aspect of the current architecture in order to analyze gaps and develop transition plans. We analyze the current architecture only enough to gain an understanding of our starting point, and spend the majority of our time modeling the target state and developing transition plans. Current systems and technology data are essential of course, as these items (in conjunction with our operational analyses) provide the basis for the logical and physical realization activities that chart the migration path. High-level “as-is” business and data models are helpful for discovery and orient purposes, but our approach is based on developing requirements in the context of target mission performance so we can begin to produce executable plans for development of required capabilities. We follow a four-phase process in our architecture engagements. We perform Phases 1 and 2 iteratively until maturity of all major missions or business threads. As noted in Figure 2 and Figure 3 our architecture engagements normally begin with a review of existing documentation – doctrine, CONOPS, existing process models etc. – that reflect enterprise strategy. We focus on the performance of expected missions, developing an understanding of the semantics, the operational roles, and the key activities, data exchanges and rules documented in our use cases. As questions arise, we interview subject matter experts (SME) who provide additional clarifying information and updates to existing documentation. Frequently, we capture this information using our operational analysts close to our client locations. The analysts identify the series of use cases that comprise each mission thread and develop preliminary UML artifacts then forwarded to our Architecture Center of Excellence for further development and analysis, including 2D animation products. Activities in phases 1 & 2 include the following: · Phase 1 - Preliminary Operational Model, including: ü Discovery of major mission threads and their activities through documentation review and stakeholder interviews ü Development of Preliminary Operational Model artifacts depicting current and/or target processes ü Since our entry point is modeling mission execution, we could also “reverse engineer” CONOPS from our models if that documentation isn’t available · Phase 2 - Validated Operational Model, includes: ü Application of our Center of Excellence architectural standards ü Establishment and configuration management of an enterprise repository ü Refinement to a baseline model supportive of downstream Service Oriented Architecture (SOA) development ü An animation of mission threads suitable for executive review ü Validation or incorporation of changes to the baseline model ü Development of a validated UML operational model including a windows media file of the animation with voice-over suitable for change management or training efforts A significant amount of collaborative effort is required during the first two phases among Serco Analysts and Architects, and Client Executives, Stakeholders and Subject Matter Experts. This collaboration occurs iteratively and produces a number of deliverables for each major mission, as shown in Figure 6.
Figure 6 – Animated Operational Modeling Ensures Stakeholder Buy-in Our architecture development process is unmatched by
any other. We developed a After developing use case library elements, we enter Phase 3. Enterprise level mission threads typically contain 10 or more use cases from start to completion, so it isn’t unexpected to develop a library of 100 or more uses cases in the enterprise repository (depending on the scope of the enterprise). We analyze in a number of different ways to develop a logical sequencing plan for development projects. For example, infrastructure capabilities required for SOA implementation will be at the forefront. This could involve network build outs, logical access capabilities or the development of reusable SOAP-based transport mechanisms to integrate the array of mainframe, client-server and Web-based technologies that likely comprise the existing physical platforms providing services. Use case frequency is another consideration – use cases that support the greatest number of missions should be developed earlier in the transition plan unless some pressing real world considerations drive the priority of a less frequent use case. · Phase 3 - SOA Modeling, includes: ü Development of the enterprise logical data model ü Logical Realization – dividing the Use Case into packages that are currently supported or targeted for future development ü Physical Realization – mapping the currently supported logical packages to physical platforms, systems and applications ü Sequencing – developing the priority for development projects After completion of SOA modeling, Phase 4 concentrates on planning the implementation of the development projects that will build out the desired enterprise capabilities. · Phase 4 - Transition Planning and Management includes: ü Portfolio alignment – grouping projects contributing to the attainment of each important enterprise objective for performance measurement purposes ü Multi-year integrated scheduling including dependencies between projects and portfolios so operational capabilities can be accurately projected ü Project Definition including developing requirements documents, specifications and cost estimates for the nearest term development projects; usually an annual task supporting the CPIC process We typically deliver standard UML artifacts on a compact disk formatted for Web browsing. This format provides navigation views, instructional material, animations and UML architectural artifacts. Figure 7 provides an overview of the typical UML artifacts (Use Case Diagram, Sequence Diagram, Activity Diagram, component views and deployment views) delivered for each use case model.
Figure 7 – Typical UML Artifacts Delivered with Each Use Case Our UML approach provides 100% traceability from Concept to code! SummarySerco’s object-oriented approach to enterprise architecture provides a proven and industry-leading capability to manage today’s complex Web and network-based SOA transitions. Key discriminators such as requirements-in-mission-context, enterprise level use case abstractions, architecture-driven 2D mission animations, and a leveraged Enterprise Architecture Center of Excellence differentiate our approach. Our processes and tools capture all the moving parts necessary to provide a “CONOPS-to-code” capability, including the ability to align the expectations of an entire command or agency, from the highest-level executives to the project managers and developers responsible for development projects that close capability gaps. Figure 8 provides an overview of the CONOPS-to-code traceability that allows architecture to bridge enterprise strategy to portfolio management.
Figure 8 – CONOPS-to-Code Strategy to Portfolio Management Our UML modeling strategy provides a well-defined
process to allow decision makers to use architectures [1] Newcomer, Eric; Lomow, Greg (2005). Understanding SOA with Web Services. Addison Wesley. [2] Erl, Thomas (2005). Service-Oriented Architecture: Concepts, Technology, and Design. Upper Saddle River: Prentice Hall PTR. [3] IBM, Rational Unified Process (RUP) [4] Kulak, Daryl; Guiney, Eamonn (2004). Use Cases - Requirements in Context. Addison-Wesley. [5] Larrman, Craig (2002). Applying UML and Patterns. Prentice Hall PTR. [6] Zachman, J.A. (1987). A Framework For Information Systems Architecture. IBM Systems Journal, Vol. 26, No. 3.
|
