The Turning Point: A Novel About Agile Architects Building a Digital Foundation

Meeting: Information Systems Architectures and Technology Architecture

Date: October 8

Present: Kathleen Stone (KS), Carl Highfield (CH), Nick Ross (NR), Terri Nichols (TN), Rakesh Gupta (RG), Greg Morrison (GM), Philip Potter (PP), Jamar Johnson (JJ), Chris Keller (CK)

CH begins the meeting and says he cannot believe how quickly we have been able to put together the Solution Architecture for this important initiative. It is a tribute to the great work on the part of the Business Architects who have done a fantastic job of understanding our gaps and prioritizing the opportunities with the business so we have a solid roadmap and transitional plan by plateau. Also, CH is impressed by the reference architecture developed by CK last year. It really enabled us to go fast.

CH introduces CK, who will lead us through the Information Systems Architecture.

CK begins by thanking KS and CH for the opportunity to work on this incredible initiative that will change the way business is done at ArchiSurance. He also wants to mention that we really need to ensure that we have good Architecture Runways available for developers when they are planning MVPs. For some reason, they think that the architects are always trying to put up roadblocks. The truth of the matter is when they go around us they often go down a path that results in a working MVP that will not scale in our environment. If we had a good runway in place, the environmental, security, and policy constraints would be known up-front versus finding out much farther down the road. They would also have a better understanding of the quality attributes required to make their MVPs scalable and consumer-friendly. CK recommends that we need to work on our relationship with DevOps and gain their trust by giving them enough runway in a timely manner that allows them to develop quality MVPs. That means that we need to stay involved as they go through their development Scrums instead of dropping off an initial architecture and then leaving.

CH agrees wholeheartedly.

JJ says he has been thinking about this as well and is more than willing to work side-by-side with the developers through Scrums to advise them when they are making a decision that will bite them later.

There is full agreement.

CK presents Application Cooperation Viewpoint, the application cooperation viewpoint, which describes the relationships between application components in terms of the information flows between them, or in terms of the services they offer and use. This viewpoint is an overview of the baseline application landscape of the organization. It is used to express the (internal) co-operation or orchestration of services that together support the execution of a business process.

CK shows the target application cooperation viewpoint (Target Application Cooperation Viewpoint), created to show Business Process to Application alignment. It describes how applications are used to support one or more business processes, and how they are used by other applications. It can also be used in designing an application by identifying the services needed by business processes and other applications, or in designing business processes by describing the services that are available. Since it identifies the dependencies of business processes upon applications, it may be useful to operational managers responsible for these processes.

The behavior of the data warehousing solution, in the context of data acquisition on the one hand and the business processes and functions on the other, is shown in Application Behavior Viewpoint (Target). The insurance premium of individual customers is based in part on the data they acquire from different devices. This data is processed to create customer-specific profiles that are input to the calculation of their insurance premiums. At an aggregated level, this data is also used to develop new kinds of insurance products and to assess and adjust the overall risk exposure of the company.

CK moves on to show the results of a global gap analysis for the Application Architecture (Application Architecture: Gap Analysis). Several application components that exist in the Baseline Architecture are no longer present in the Target Architecture: the separate back office applications and the separate “Legal Expense CRM System” and “Legal Expense Back Office System”. The CRM functionality for Legal Expense insurance customers is taken over by the general CRM system; therefore, this does not require new components (although it may be necessary to adapt or reconfigure the existing general CRM system, this is not shown in the gap analysis). In addition, a completely new back office application suite and new data warehousing solution are introduced.

CK continues by talking about the ArchiSurance Data Architecture which describes the major relationships between its conceptual business objects and its logical data objects. The information structure viewpoint is comparable to the traditional information models created in the development of almost any information system. It shows the structure of the information used in the enterprise or in a specific business process or application, in terms of data types or (object-oriented) class structures. Information Structure View Showing Main Business Objects shows a subset of the business objects that ArchiSurance defines. Part of the customer information is an insurance file, which is composed of insurance requests, insurance policies, and damage claims. A number of specializations of the Insurance Policy object are defined, one for each type of insurance that ArchiSurance sells.

CK goes on to say that the purpose of the Data Dissemination diagram (Data Dissemination Diagram) is to show the relationships between the data entity, business service, and application components. The diagram shows how the business objects are realized by application components. This allows effective sizing to be carried out and the IT footprint to be refined. Moreover, assigning business value to data gives a clear indication of the business-criticality of each application component.

CK says this is a great opportunity and asks if there are any questions on the Information Systems Architectures.

PP asks if CK has identified all of the information security policies that are relevant for the data that will be collected about our customers.

CK replies that he believes all of the information security policies have been identified in the Enterprise Architecture system. They were easy to find as we adopted recent improvements in the IT4IT Reference Architecture, so our product/service lifecycle now captures information from the conception of an Idea through to Operations. CK reports that he has been working with the GRC group on the information security plan for about three weeks. The plan explicitly states how we will adhere to each policy.

CK emphasizes the need to have a bulletproof plan for protecting our customers’ personal information.

PP is glad to hear that CK is so far along on the information security plan.

KS agrees and points out that CK is also in line with our first two principles:

CK hands over to JJ to go through the Technology Architecture.