Solution Architecture Guide Working example for an organization attempting to implement a Data Governance Framework

Transcription

1 Solution Architecture Guide Working example for an organization attempting to implement a Data Governance Framework Measuring, Creating, & Delivering the RIGHT Value Page 1

2 Solution Architecture There are 4 separate areas of exploration, each of which builds upon each other in a progressive manner in Step 3: Business Architecture, Operational Architecture, Information Architecture, and Application Architecture. Each area represents a distinct architectural concern and has its own set of techniques and deliverables. The order is important since it allows the team to first understand the scope and breadth of concerns that address the larger business needs for addressing the recommendation. Once those are clear, the team should be able to define the operational concerns so they understand what processes are needed to support the business needs given the assumptions, risks, and scope. The next logical step is to define the information architecture concerns in order to assess the complexity of change required to support the operational needs. Finally, the application architecture can be explored so we understand the conceptual architecture required to support the business, operational, and information architectures as well as component breakdown (including interfaces). Once the 4 areas of architecture are defined, the team will be in position to identify the list of projects, which should be considered to implement the solution. Walking through each of the areas of architecture requires an overview for each area (see Research and Reference Materials below covering Solution Architecture). Business Architecture The concepts we captured in Step 2 are used to populate the list of needs covering Business and Operational perspectives. Examples of business needs include: The business is looking for ways to improve the quality of data (focused on addresses), enable self-service, and improve vendor management. Measuring, Creating, & Delivering the RIGHT Value Page 2

3 Examples of operational needs include: The operational teams are looking for ways to validate and cleanse addresses, ensure operations are properly staffed, and processes are well managed and consistent. Once the needs are captured, we need to capture some of the key scenarios (use cases), which may push the complexity of the solution. These scenarios represent some of the tougher challenges that operations staff experience today and some of the challenges that may occur in the future. Examples of scenarios include: Note: These are only a small sample of the use cases and each of these will need to be explored more fully as part of the business requirements. We also need to capture the Assumptions, Constraints, and Risks to provide a more complete perspective of the business architecture concerns since there are many unknowns at this early stage of analysis. The Assumptions and Constraints are used to guide the scope and approach for the solution. Examples of both include: Measuring, Creating, & Delivering the RIGHT Value Page 3

4 The risks are used to manage the expectations for the business and technical staff. These may impact the timeline, budget, and effort required to build and deliver the solution. Each risk is accompanied by a suggested mitigation approach, but these may change once the business analysis is underway. Further, the numbers of risks will likely increase in the early stages of the analysis as the project team gains a deeper understanding of the challenges associated with each project(s). One other item that typically accompanies the business architecture concerns is the identification of core patterns. These are common sets of capabilities, which already exist in other organizations, and/or which may be prevalent in proven solutions (meaning we don t have to reinvent it we should be able to leverage it). Common patterns include ways to perform business activities (common types of processes), ways to make decisions (common types of rule sets), ways to perform calculations (algorithms and formulas). There are other types of common patterns that can be used across the organization, depending on the problem domain. When these are identified, Measuring, Creating, & Delivering the RIGHT Value Page 4

5 they can be used to drive decisions for buy vs. build when pursuing implementation strategies for a solution. Operational Architecture The next step involves identifying a list of the core processes used to support the operations involved in the solution scope. Core processes represent the most important activities involved in the solution (they are typically involved in day-to-day activities). In addition, the DG Operations team needs to identify a list of exception processes. These processes are considered edge cases which are challenging scenarios. Exception processes are used to explore the level of complexity, which might push the boundaries for the solution. Once the processes are identified the next step involves modeling the processes in a systematic manner. We introduce the SIPOC (see Research and Reference Materials section below) as a tool for detailing the key aspects of each process. SIPOC (Supplier, Input, Process, Output, and Customer) is a disciplined process used to decompose the steps within a given process and capture the core details that used for each process step. We expanded the SIPOC with 2 additional columns to capture information associated with controlling and monitoring each step in the process. A sample of the detail can be found below (the working spreadsheet is actually much larger & comprehensive): The SIPOC created in this methodology is a subset of a more expansive process that is followed during the business analysis for one or more future projects. The purpose of using a lightweight approach for SIPOC is to explore the core processes (and any exception processes) in more detail to gain a better understanding of the operational concerns. The operational architecture is the primary source for detailing the information architecture. Measuring, Creating, & Delivering the RIGHT Value Page 5

6 Information Architecture The next activity involve mapping out the information flows to identify all of the data repositories (files, databases, operational data stores, data warehouses, etc.) required to support the capture of data for each process (identified in the SIPOC). The information flowing to & from each repository is identified as well as rule sets used to control processes and support information flows. Information flows need to demonstrate how the core processes will be supported. The diagram needs sufficient detail to help the business SMEs show the inputs & outputs, as well as where data will be pulled from to support reporting needs. The following diagrams are examples of information flows for data governance: Measuring, Creating, & Delivering the RIGHT Value Page 6

7 Rule Sets are important to explore since they provide additional insights on complexity (breadth & depth) for the solution. The exercise for modeling rules involves identifying types of rules and classifying them into sets of related functionality. In the DG Operations Methodology, we only explore the rule sets at a high level of abstraction to guide the application architecture as well as guide the estimation process. Managing rules will become an increasing important competency as the agency consolidates systems and captures knowledge that is spread in many different locations (including people s heads). The business SMEs need to validate the Information Architecture with the Information Architect leads (see SIPOC below) to ensure it supports the Operational Architecture needs. Measuring, Creating, & Delivering the RIGHT Value Page 7

8 Application Architecture The final piece of the solution architecture is drafting the application architecture, which incorporates aspects covering all of the prior 3 architecture concerns. We first start with drafting the big picture for the overall solution using a Conceptual Model. The purpose of the model is to define an abstract representation of capabilities that support all of the prior architecture concerns (business, operational, and informational). The capabilities can be initially laid out using sticky notes, which can then be sorted into common buckets representing patterns of capability. These buckets are then assembled into a pragmatic structure outlining the conceptual model (see example below): The conceptual model above has additional attributes in shapes and color to provide additional insights on how the application architecture for the solution fits within the greater enterprise architecture. The pink color represents the core capabilities included in the solution. This is the primary focus for what needs to be included in the list of projects required to design, build, and deliver the solution. The blue color represents the various pieces of infrastructure that should be in place in order to support the core capabilities for the solution. These would ideally be in place and only require minor configuration and/or repurposing to meet the needs of the solution. IF they do not exist, then they would be additional IT Infrastructure projects that would need to be defined, funded, and slotted in advance (or parallel) to the core projects to implement Measuring, Creating, & Delivering the RIGHT Value Page 8

9 the solution architecture. The green color represents the operational structures (teams, processes, and governance), which would need to be put in place in order to leverage the solution (technology only exists to support the business and operational needs). Once the conceptual model is defined, reviewed, and approved the next step is to create a functional decomposition of each of the core capabilities ( buckets ) to provide sufficient detail to ensure the solution fully addresses the business, operational, and informational concerns. Ideally, each one of these would also identify common patterns of capability (sets of services not necessarily tools), which need to be in place to address the prior architecture concerns. This is an iterative process and requires some skill with abstraction, familiarity with common patterns of capability within architecture components and an ability to demonstrate traceability from the application architecture back through the prior architecture concerns. Walking through the prior artifacts is helpful as well as having the DG Operations Team discuss scenarios within each area of architecture to identify any major gaps. Once the team has completed their work, they should be able to produce a simple component model like the one below: Measuring, Creating, & Delivering the RIGHT Value Page 9

10 The last piece of the application architecture involves mapping out the key integration points that the solution will need to address (both internal & external points). The details are left to the Information Architecture diagrams (discussed previously), but this is a good point for abstracting them into patterns of interfaces to promote an enterprise view and identify opportunities for reuse that both business analysts, architects, and design teams may want to consider. The example below is a bit simplistic, but provides an outline for cataloguing some of these integration patterns: Once the application architecture has been documented, the DG Operations Team is ready to generate a list of projects to implement the solution architecture. Note: The team may also want to highlight any additional recommendations (from Step 1) and any infrastructure projects (from Step 3 items in blue), which need to be addressed either before or in parallel with the core projects for the Solution Architecture. Measuring, Creating, & Delivering the RIGHT Value Page 10