Abstract:
Enterprise architecture framework is used to carry on enterprise architecture work for enterprises. Enterprise architecture helps enterprises to deal with today challenges such as low and regulation compliance, agility of the business and the IT, managing portfolio, making the CEO vision into reality and others. Dealing with business and IT agility touches SOA and services. In this article we’ll see how we can use architecture framework to map enterprise level services and set their granularity.
What is enterprise architecture?
Enterprise architecture is a holistic view of the enterprise which enables us to know the current architecture of an enterprise, where we want the enterprise to be, and what the gaps between current and the future situation. Enterprise architecture also plan what are the actions (in term of projects) that we need to take to fill those gaps. Enterprise architecture should make sure that those projects will take place in reality and by the architecture principles, standards and blueprints. Architecture is all about defining what are the building blocks that compose a whole and the relation between them. In order to get this holistic view we need to architect the Business, Information, application and technology of the enterprise.
The framework:
Enterprise architecture work is not one of the easiest tasks that enterprises are doing due to the complexity of combining four different domains together. To help enterprise architects to know what is needed to be defined to get a holistic view of the enterprise and how to do it, there are several enterprise architecture framework available. This article focused on enterprise architecture framework.
enterprise architecture framework composed from three main components:
1) Architecture Development Cycle (ADC): step by step instructions what needs to be done, how to do it and by whom to get complete enterprise architecture. The ADC is like a practical methodology to create enterprise architecture.
2) Repository: definition of types and instances of building blocks needed to model each one of the enterprise domain (Business, Information, Application and Technology) and their relations.
3) Resource base: collection of accelerators that might help enterprise architects to do their work faster and better. The resource base includes questions and answers, best practices, tolls, how to and services.
In respect to those components the framework is also based on three main pillows:
1) Basics: SAP existing knowledge and experience in different industries. This information exists internally or externally in the form of solution and business scenario maps, reference models, standards and more. This pillow related to the resource base
2) Methodology: this pillow is the architecture development cycle together with other available services (such as ESA adoption, value engineering, business consulting and more). Each one of the available services is mapped to part or the entire repository building blocks. Mapping to building blocks simply defined in unified way the building blocks needed as input for the service and what is the service output in terms of building blocks.
3) Tool: In order to carry on such a work a tool that is able to store all the repository building blocks is needed. This tool should also support modeling capabilities, visual presentation of building blocks and navigation and queries abilities.
The framework is a collection of methodologies, best practice, SAP knowledge and experience, tolls and definition of building blocks to create holistic view of the enterprise and to help the enterprise architects to perform his daily duties. This article is about one of the framework services: Mapping of enterprise level services and their granularity.
We can’t get into more detailed discussion about the framework components and pillows in this article.
Before we’ll explain how to perform this services, let’s define what types of services we expect to find in an enterprise and what the relation between them are.
Services and level of services:
SAP defined enterprise services as “a standards-based way of encapsulating enterprise functionality and exposing it as a reusable business service that can be combined with other services to meet new requirements. Enterprise services, defined by SAP and its partners and customers, can be assembled together to compose new applications or enable new business processes." (Source: SAP)”. This definition is too general, hence for the sake of this article we suggest three subset definitions: logical enterprise level services, composite services and technical enterprise services
1) Technical enterprise services: Are Enterprise services implemented as web services or any other technology. Those are the technical services that exposed by SAP or other vendors/internal developments. Technical enterprise services usually defined by vendors/internal projects.
2) Logical enterprise level services: those services refer to the enterprise level services needed by the enterprise in order to operate. Such a service might be “Create new customer”. Logical enterprise level service can be mapped to one or several SAP and non-SAP technical enterprise services. Logical enterprise services are the services that the business needs (regardless the implementation that will be done by IT to supply them). Logical enterprise wide services defined by enterprise architects and used both by business and IT guys.
3) Composite services: when a logical service needs several technical enterprise services to serve the customer needs and this composition of several services can be reused in other services, then a composition of services is created. Those are composite service. Composite services are usually defined by solution architects.
This article suggests a methodology to define logical enterprise level services. We aren’t going to explain who to define composite architecture. Defining the scope between enterprise architects and solution architects might help you to understand why.
Scope of enterprise architects and solution architects work:
Enterprise architects and solution architects are two different roles with clear line that separate them. Enterprise architects outputs are definition of current and target architecture, list of time-lined projects, principles, standards and blueprints. Those outputs are the inputs for solution architects. Solution architects will be assigned to one or more of those time-lined projects. The solution architect should define the architecture for this project/s by following the principles, standards and blueprints defined by the enterprise architect.
Therefore the responsibility of the enterprise architect is to define all of the needed logical enterprise level services and to map them into a project that will implement them. The solution architect is the guy that will decide how the defined logical service will be implement (is it going to use composite service, call directly couple of technical services or direct call one technical service).
Using the framework to identify services:
Needed building blocks
To describe the methodology we’ll use several building blocks from the business, information and system domains of SAP enterprise architecture framework. Therefore let’s start with describing those building blocks before starting to explain the methodology.
- Goals: stand for the goals of the enterprise as defined by the CEO or the board. We are using goals and objectives to show how services are going to help the business.
- Objectives: list of objectives that need to be met in order to reach certain goal. The main difference between goals and objectives is that objectives must be Specific, Measurable, Actionable and scope in Time or SMART.
- Capabilities: what are the business functions needed to be done to reach one or more objectives. Capabilities are just what the business should be capable of doing.
- Business Processes: if capabilities are what the enterprise should be capable of, Business processes are how the enterprise is managed to reach a certain capabilities. Usually processes tend to be different between enterprises in the same industry because the same capability can be achieved in different ways (or processes).
- Roles: as it imply what are the positions in the enterprise which responsible to carry on enterprise capabilities.
- Information type: fragment of information used in a process to communicate between two roles when they perform any process tasks. Information types are related to information world and the definition of information types different from enterprise to enterprise. Usually information types are purchase orders, invoice or customer.
- Information world: information worlds are more abstract information fragments. They are collection of information types that should be owned by certain role of the enterprise. The owning role tends to use that information most of the time, while other roles use them but not on regular basis. Information world might be Customers, Workers or suppliers. The Customers information world holds the mentioned information types: invoice and customer.
- Logical service: equivalent to the definition of logical enterprise level service. Logical services received information and return information or any other business value.
- Application: software that support any business process or part of the business processes. Applications support processes by letting users access information or manipulation information.
- Technology: any technology that needed to support application such as document management, GIS, Database, application server, Enterprise Service Bus(ESB) etc’
- Infrastructure: any hardware to support technology (desktops, servers, backup robots, etc’)
- Communication: any hardware or technology that used for communication between infrastructure elements across the enterprise.
Figure 1.0 domains and building blocks
The methodology
- Step 1 (Goals and objectives):
Our first task is to identify the business goals and objectives. Again there isn’t any impact of goals and objectives on identifying services or their granularity. The only reason that we need goals and objectives in this service is to make sure that all of our services connected directly to some business objective.
Identification of goals and objectives is usually easy task since a document which contained those building blocks exists in most of the cases. If you can’t find such a document a short interview with the enterprise CxO level will help you to identify goals and objectives.
- Step 2 (capabilities) :
Capabilities describe what enterprises need to do to reach their objectives. We tend to arrange capabilities in hieratical order. From the highest level of capabilities down to more detailed capabilities. If you familiar with SAP solution maps (http://www.sap.com/solutions/businessmaps/solutionmaps/index.epx ), they are similar to three levels of capabilities.
Solution maps display the first (highest level) capabilities visually as gray rectangle. Then using color rectangles (checking the “expand all” checkbox) we can see the second level of capabilities. Clicking on one of the 2nd level capability you’ll see a list of processes which are the 3rd capability level. (You can use the Automotive OEM map by following: Industry-Specific SAP Business Maps -> Automotive->OEM to check it up).
Following SAP solution maps might help you a lot, but keep in mind that you might need to adjust the suggested capabilities to your own enterprise. We recommend drilling down to the third and fourth level of capabilities. Usually those levels of capabilities can be seen as conceptual services that the enterprise needs to operate. Part of those conceptual services will be deliver by human, part by computers and part by both humans and computers.
For now you have a map of all the needed conceptual services. The best way to work with capabilities is to display them in hierarchal view (using containers as in figure 2.0).
Figure 2.0
For each group of high level capabilities we can set what is the right level of capabilities that might be translate into conceptual services. By going through this capabilities exercise we have a list of conceptual services (that still needed to translate to logical services) and a say regarding the services granularity.
Usually it takes time to understand the different between capability and process. Once you get the different it’s pretty easy task to create capability map and to identify your enterprise conceptual services.
- Step 3 (Processes)
Processes describe how enterprises manage to perform capabilities. Behind each capability there should be at least one process that describes how the capability is done by the enterprise. To describe capabilities processes we use modeling notation that supports lanes and tasks definitions. Each lane represents certain role in the enterprise and inside the role lane all the tasks that the role perform, as part of the capability, are mentioned. Lines between tasks represent the flow between tasks and they type of the flow. This step is all about mapping the processes that will help us to understand how the capability carried on by the enterprise. Our main usage of processes in this methodology is to extract what is the information needed to operate certain conceptual service and to understand how the service should be implemented. By knowing how each conceptual service will be implemented we can see if the service scope is too wide or too narrow.
SAP can also helps us with high level processes (which describe flow between second level capabilities) by using business scenario maps. When clicking on second level capabilities in the solution map you’ll get the list of the third capabilities. If SAP defined a business scenario map, you’ll see it in the upper right side of the page. Clicking on the link will take you to high level processes that you can translate to your own modeling tool. You can use this path to see it working (http://www.sap.com/solutions/businessmaps/solutionmaps/index.epx
Automotive - OEM > Time-to-Market > New Product Development and Introduction).
If no business scenario maps exist or you need to model process of low level capabilities you should do this work by performing interviews with different roles in the enterprise. If you have to model processes it’s important to set in advance what should be the level of details for describing processes. Drilling into low level of details might extend the time needed to do the work and will impact on your ability to read and understand processes. As a rule of thumb break the enterprise into organization unit and focus on tasks done by the third hierarchy organization units.
- Step 4 (identify information types and information worlds)
This step is about identifying information types and how they composed into information worlds. Most of this work is based on the processes we just modeled in the previous step.
The first task here is to go through the processes and to identify what are the information types that used in order to do the processes. Again, information types are customer, order, worker, manufacture, car, etc’. Having the information types we can start to group them into information worlds.
The first criterion to group information types into information worlds is by ownerships. Certain information type in the enterprise should be owned by one role in the enterprise. It doesn’t say that other roles won’t be able to access this information world and manipulate it; we just say that one role responsible for it. If you have clear ownership model in your enterprise you can group information types into information worlds (such as Marketing, Production, Design, HR, Financial, etc’)
If no clear ownership model exists you can classify information types by usage of role. Most of the information types are accessing on daily basis by certain role and in less frequency by other roles. All information types that access frequently by one role in the enterprise can be grouped into Information world. For all other information types a series of discussions should be taken to agree upon the owner.
After grouping information types into information worlds we recommend trying identifying what are the information types that use internally (by the information world owner) and types that used by other roles. In a warehouse information world for example, inventory is a local information type while the order information type is also used by other roles. This exercise will be helpful in the next step.
Information worlds serve two main targets. They help to create ordered in the information jungle, thus to reduce problems in the IT world (mainly in the information domain). Information worlds are also serving as a semantic model of the enterprise. Logical information model can be easily translated into MDM model, but that deserve a dedicate article.
In this methodology we’ll use information worlds to identify what are the logical services for our enterprise.
- Step 5 (identifying logical services from conceptual)
Lets recap what we’ve done by now. We start with capabilities and identifying which capability level should be declared as conceptual services. Do understand capabilities we model the processes to understand how the enterprise perform capabilities. Using the mapped processes we manage to identify what are the information types needed to perform the processes and we group information types into information worlds.
Conceptual services can be delivered by humans, computes and combination between them. Logical services are information based services. Information based services are services which use information as input/output. We aren’t interesting in the information needed to perform the work at this step. This data is irrelevant now since it will influence the internal implementation of the service. Therefore, having conceptual services can be the input for identifying logical services.
Conceptual services linked to business processes, which linked to information worlds. Using all of those building blocks and their relation we can start to analyze what are the conceptual services that use information to do their work. There are two options to mark conceptual service as information user. First if it uses information directly. Secondly, if one of the capabilities directs sons (sub-capabilities) are using information to perform their work.
As information technology professionals we want to express our logical information in conjunction with the information that the need to perform their work. To accomplish this task we have to find out what are the information worlds that host the information types. If a conceptual service (capability) just uses one information type we’ll associate the conceptual service as logical service of the relevant information world. A conceptual service that uses several information worlds will be associated to the relevant information worlds. Sub-capabilities will be mapped to information worlds as described above. Each sub capability will be covert to logical service and all of those logical services will be associated to their “predecessor” conceptual service (capability).
After associating logical services to information world/s we can use the information world’s information types to define what are the logical service information inputs and outputs in terms of information types.
Now comes the most difficult part of our work. This part difficulty is due the political aspect that encapsulate in it. Information worlds have roles that own them. Information worlds use logical services to expose data to other roles in the enterprise. Therefore for each logical service we need to create a SLA that will be agreed both by relevant information world owners and the service consumers.
In the end of this step we have a list of logical services. Each logical service linked to information worlds and conceptual services and it information inputs and outputs are already declared.
- Step 6 (aligning logical services to applications)
Equipped with all the logical services needed to operate the business we can now find out what are the applications that provide today one of those logical services and what are the applications that might expose logical services which aren’t implemented yet by applications.
Here you might use SAP ESR to find out if any logical service is completely support by one of the available services in the ESR. Having such a match you can set that the SAP application which supplies this service should be the application responsible to expose this service.
Logical services that need composition of application to be used are more difficult to associate with applications. If you have enough knowledge about the enterprise application landscape you can find out what are the applications that needed to supply certain logical services. Anyway, remember that your duty is to set projects to close gaps and to set principles, standards and blueprints. It’s the solution architect work to map logical services to composite or technical services.
- Step 7 (implication of services on technology, infrastructure and communication)
To close the holistic view of services mapping we also want to document any technological, infrastructure or communication building blocks that needed to be conceder to support services. Services need enterprise service bus to be able to communicate one with each other. Therefore we expect to see an ESB building block in the technology view. Service that required 24*7 availability should be support by infrastructure and communication building blocks (such as load balancer) to enable this requirement. Services that deals with huge amount of data need hardware (such as SAN/NAS storage) to support it.
Mapping all of the technological, infrastructure and communication building blocks will help us to see that holistic picture and prepare the enterprise in such a way that when services will be available they will also be compliance with an SLA that already signed between the service provider and it customers.
Conclusion:
This article suggest a methodology that uses enterprise architecture framework to identify enterprise level services, their granularity, allocation to expose them and technology, hardware and communication needed to support those services.
Using the framework building blocks and the tool we can map the business capabilities in hierarchal order and to identify what hierarchy level can be conceptual services. Then we use business processes and roles to describe how those capabilities are performed by the enterprise. Form those business processes we can extract the needed information to run capabilities (conceptual services). Using this data and base on the criteria of information usage, of we can find out which one of the conceptual services can be seen as logical service.
Using the framework building blocks let us define attributes for each one of the building blocks. We can define pure business attributes to capabilities (such as availability or compliance to lows and regulations) and information oriented attributes to information worlds (such as capacity or exception handling). Those attributes don’t have direct contribution to service mapping, but they help a lot to make sure that services implementation will be as close as possible to real business needs.
Aligning IT to the business is one of the main concerns of enterprise architects; therefore we also added goals and objectives to the methodology and associated them with services via capabilities, processes and information worlds. Adding those building blocks enable us to show how services support the business and what are the services that support given business goal.
2 Comments
