Natty Gur

What needed to be monitored to get better Governance

2009-10-23T11:42:00Z

Collecting, modeling, validating and analyzing data from different domains to create to-be architecture in a form of principles, standards and blueprints are not enough to create successful enterprise architecture. The real challenge of enterprise architecture is the ability to make it happened in projects. If you can't find signs of enterprise architecture outcomes in running projects, all the work that you've done worth nothing. In this post I'll try to describe what are the main task that I'm doing to create successful enterprise architecture governance processes.

I'm usually splitting governance into three types:
Formal: Creating hooks in IT SDLC, IT processes and business management processes to keep track on changes and conduct reviews where needed.
Active : Participant actively in IT projects (as part of the team) to catch and fix compliance issues when they are arise and not after they are solved, and the project is ready to deploy.
Passive : create set of IT projects compliance reports based on compliance parameters to create visibility of architecture compliance and pressure on projects.

The formal and the active governance required trigger points in different enterprise processes to know all the changes in the enterprise four domains, so we can react in the right way. Listed below are the triggers that I getting use to put and the data that I'm monitoring.

Requests for new projects :
What we have: knowledge of potential projects
What we can do: make sure that new projects fits into our portfolio and roadmap.

RFP / internal analysis :
What we have: Business capabilities, business processes, logical information model, relation to other systems, externals business units .
What we can do: make sure that the project using EA language. Validating EA repository accuracy (new building block instances and relations). Make sure the project fits EA guidelines.

Architecture Review
What we have: Main project modules, relations to other systems, requirements from technology layer and definition of non functional requirements (response time, data volume, auditing, security, availability, etc').
What we can do: Validate compliance to blueprints and principles. Validating EA repository accuracy (new building block instances and relations)

Design review
What we have: Low level derails of project implementation (Not in EA level).
What we can do: Validate that project still keeep compliance after going down to details and solving problems that the project wasn't aware of in architecture phase.

Code review
What we have: Code written to implement design (Not in EA level)
What we can do: Design is good but implementation might change it significantly. We want to Validate compliance of the finished product.

Deploy to production
What we have: Applications, databases, servers, products, technologies, storage devices , communication devices.
What we can do: Validate our repository against deploying data and make changes of the as-is architecture (if necessary).

Deploy of new change / enhancement to production
Same as deploy to production just this time we want to know just about the changes that has been done to the existing project

New capacity planning of databases/storage/servers/network
What we have: databases, storage devices, servers and network devices.
What we can do: align between EA to-be architecture and reality. Making sure that capacity planning following architecture blueprints and principles.

Purchasing of new Product, database, storage, Server, Network device
What we have: Products , Databases, storage devices, servers and network devices.
What we can do: align between EA As-IS architecture and reality. Making sure that purchased goods are done by following architecture blueprints and principles.

Personal changes in IT (change IT group, leave IT or enterprise)
What we have: Responsibilities and ownership.
What we can do: Validate IT and business assets responsibilities and ownership.

Communicate highly complex information to a broad audience

2009-09-27T10:39:00Z

One of the common tasks that enterprise architects are dealing with on a daily basis is the need to explain complex IT issues to different audience, including non IT audience and CxO level. I can find many discussions around this requirement but I can hardly find any best practices or advices. In this post I'll try to share my experience and knowledge and I'll be happy to hear other experience as well.

The are 5 main principles that I follow when I have to prepare for presentation of complex domain information for non domain members.

Focus: I started to use this technique when I had to present to CxO, due to time restrictions that usually coming with those meeting, But I'm using it for any audience now. This technique enforce you to deliver 3 main messages to your audience, No more. The Idea is to create a matrix of 3 rows and columns. Each first column in each row should present one message that you want to deliver and the two following columns enable you to extend a little bit your message. This is quite challenging since it takes time to find out what are the main 3 messages that you want to deliver and to sharpen you message into 3 slides. The benefit is that you're coming focused to the presentation and you won't find your audience bored. Focusing also yields simplicity.
Visualization (and animation): A picture is worth a thousand words. When I need to show complexity or to show some Ideas that are based on huge amount of data, I'm always looking for a way to show the message in a graphical way. Two examples here. In the first one I want to show that IT is really complex to our CEO. So I took all of our IT assets and grouped them in to four main domains. On top of this grouping I added all mapped relationship between IT assets. The result was a jungle of dots and line. The message was transferred and accepted very fast and easy.

The second example was about transferring the message that we're building an IT structure that will be based on shared and reused services and components. In this case we created a pipeline with two levels, external that demonstrate projects work that needed to be done to create overall business solution and internal level which represent all the common services and components. We use animation to enlarge the internal level and minimize the external layer to demonstrate what we pursuing. We also split the internal layer to several segments the explain what type of services we want to provide.

Examples that everyone knows from life. I think that the most common example here is the usage of city planning when expanding enterprise architecture. People know and understand city complexity and can easily relate enterprise architecture to it.

Example from enterprise business domain. This principle works mostly when I have to present something from IT world to Business domain (VP, SVP, CxO). The idea here is to take business example that demonstrate the same problem that I want to discuss from IT domain. If for example I want to explain the need to create MDM, I would ask the CEO if he can manage the company if any division has it own number and definition to the same product that we're selling (same product has different catalog number in different unit of business).
Break and abstract: If I have to present something that it complex and contain a lot of information (how to identifying needed, existing and missing services) , I tend to break it and abstract it as much as possible. The first thing is to break the complex idea that I need to deliver in to a list of topics ordered by relations between them. When Finalizing with the list and dependencies I can start presentation from high level process that shows what we up to. Then I'll address each entry in the list and summarize the presentation with the process again.

I hope that I didn’t miss any principles that I'm using, But what about you? What are the principles that you're using to deliver complex messages?

How to retire (respectfully) legacy systems

2009-09-11T07:10:00Z

They served us for a long period of time, but (for different reasons that I wont cover in this post) now the time to say good bye and to retire them. Legacy systems exist in each and every enterprise and we all have the experience of retire them. The question is whether your enterprise have a predefine process to retire legacy systems or is just process that happened? In this post I'll try to share a retirement process for legacy systems.

From what I've seen so far in most enterprises, legacy systems are not going through a process of retirement they are simply abandon (from IT point of view). The users (or should I say most of the users) aren't using the system anymore but, batches keep on running, backup processes still running, they still take some place on the disk, their databases might still take space, etc'. It is worthless to say that if you're going through a process of mapping your IT assets you'll find most of (not all of) the legacy systems and you'll start a process of retirement.

The process, which I'm getting use to do, is composed from five main steps:

Mapping: mapping of the legacy system components and their relations to other IT assets. Usually the mapping includes: Permissions, system services (and their consumers), system references from menus, system programs (PL1, Natural, Cobol, VB 6), databases or data files, batches, system data used by other systems, navigation to the system, usage of software or technology infrastructures, usage of other systems data, etc'

Discussion: a formal discussion to approve the system retirement with participant from all relevant organization units (following the mapping)

Writing shutdown procedure : Writing a detailed procedure of all the tasks, task owners and tasks order that needed to be taken when taking the system down. The shut down procedure should be sent to all related IT teams, users and support center.

Neutralization : taking down system component, with the ability to restore them back to working state very fast. The neutralization includes : taking system references from menus, services and programs. Taking down system databases or renaming system files. Stopping batches. This step check if there are surprised users or unknown navigations or usage.

Archiving : taking down system security settings, remove linkage from other systems, removing system components and achieving them. After a month of two if no access recorded to system components we can remove them and archive them for further use (how we handle complex IT/software issues in the past). When archiving system, we inform infrastructure providers that the system is down and it wont consume infrastructure services anymore.

Using Hungarian Cube to demonstrate enterprise architecture

2009-08-08T10:10:00Z

Those days I'm helping a bank in Thailand to start an enterprise architecture team and practice. As usual I found very technical group that was assigned to do the work. One of the first thing that I tried to do, is to explain them the different between what they have been done so far (solution architecture) and what they need to start to do from now on (enterprise architecture). In a nutshell, I keep on trying to explain that while you doing solution architecture you focused mainly on one aspect of the enterprise domains (Business, Information, Application and Technology), or small fractions of the enterprise. When doing such work you focused on low level of details, but when you're doing enterprise architecture your scope become wider and the level of detailed that you have to deal with become higher. As much as I tried to explain it they didn’t manage to get it and they staid in low level detailed technology architecture. On one of the knowledge transfer session that we had I got an idea to use the Hungarian Cube to demonstrate the difference between EA and solution architecture, and …. It simply worked!

I started the show holding the cube very close to my eyes. What I'm doing right now is technology architecture, I said. I see just one side of the cube, but I can see in detailed what exist on each surface of each rectangle of this side. That's what you are doing now, Having the cube so close to your eyes you see and capture every aspect of the cube surface (or technology architecture). Although this is an important work this is not EA.

In order to do EA we MUST take the cube away from our eyes, so we can see three sides of the cube and the relations between them. Actually we need to roll the cube to see all 4 elements of the cube. When we take the cube away from our eyes we can see the holistic view of the enterprise, which is enterprise architecture. When we take the cube away we can't see anymore all the details on the cube sides surface, therefore we can't capture low level details of the cube surfaces (or different enterprise architecture domains). As anything in life there are compromises, we can see the holistic view of the enterprise but we can’t do out work using the same level of granularity as we've done while doing technology architecture.

Information Architecture - The bridge between Business and IT

2009-08-03T12:24:00Z

Information is truly the bridge between business and IT. While collecting and modeling business capabilities and business processes we are using information as inputs and outputs for business capabilities and processes. Information architecture is also heavily used in application architecture. We collect and model which applications manage which information, how information flow between applications, how applications and technology enforce information security, etc'. Actually it is not surprising that Information is the bridge, applications are created to support business users functionality and information manipulation. In this post I'll introduce what is my approach to Information architecture.

I'm modeling information architecture in three levels: conceptual, Logical and Physical. Conceptual information modeling is an effort to collect the main information types (something like subject areas) which is used by the business in order to reach enterprise's goals and objectives. Conceptual information example could be a Customer or Settlement. Logical data modeling is an effort to break conceptual information into logical entities. Each entity resemble set of data that is used by the business as one unit. Logical modeling also include capturing relations between entities and setting non-functional attributes for each entity (availability, security, Audit and control, Availability, backup, etc'). Physical modeling includes databases schemas and the relations between physical tables and logical entities.

Information architecture also include modeling of information flow between business capabilities and modeling of information flow between applications. Mapping between information and applications that own or responsible for maintaining information entities concider to be part of infrmation architecture as well.

Identifying and modeling information has a lot to do with business capabilities and business processes. While collecting and mapping business capabilities (in different hierarchy), I tend to collect conceptual and logical information, which used as input and/or output for capability. Usually I'm using the conceptual information for capabilities in level one to three of the capability hierarchy, and logical information (entities) for capabilities in the fourth and fifth level of the hierarchy. I'm also using capabilities hierarchy to get relations between conceptual and logical information.

Setting logical information (entities) non-functional requirements also have a lot to do with business capabilities. Actually the non-functional attributes of logical information are inherent from business capabilities that are using information entities as inputs. If, for example, given business capability need to be available 24*7; all the data that this capability is using as an input/output should be also available 24*7.

Business capabilities and business processes are also helpful to set information security attributes. Accsess rights (Read, Delete, Add, Creat) and information compartmentalization (Show part of information on a need to know basis) can also be set by walking through business processes and capabilities and finding out who is using which information and how.

I'm using BPMN to model information flow between business capabilities and application architecture interfaces to model which information is flow between applications or products. Information flows are important components of information architecture for two reasons. 1) Information flows helps to understand how information interchanged between people and applications. 2) part of the non-functional attributes of information are impacted from the interaction of certain information in information flows.

Adopting logical information model, as the standard way to exchange information between application and people, is consider to be good practice. Using this approach applications know to get and return logical information entities, but internally they can break or unified information entities by their internal application schema. Such approach creates a common language between applications and different roles in the enterprise.

Mapping between logical entities and physical tables also help us to better understand our enterprise data. Logical entities resemble the way business work with data and it also serve as common language of applications. Mapping entities to tables helps to find and manage duplicate data as well as to get better understanding on impacts of changing certain schema structure.

Business Capabilities and Business Strategy

2009-07-26T13:22:00Z

Every time that I'm writing about business capabilities I'm receiving replays that capabilities won't help me to get business strategy and without business strategy I cant defined the business to-be architecture. In this post I'll try to explain how I'm using business capabilities to create business "to-be" architecture, as well as getting better understanding what IT solutions existing or missing to support the new business strategy.

Part of the business architecture work that I'm doing is to get business goals and objectives. Business goals are the directions that the enterprise leadership mark to be achieved. Business goals set direction and they are usually high level and without any time dimension. Business objectives are much more specific, they are accurate, measurable, has time limitation and realistic . Each business goal has several objectives to support it. So, my first task is to collect business goals and objectives and map relations between them.

When I'm done with Objectives, I'm starting to collect business capabilities, or what the business is doing in order to achieve business objectives. Usually I tend to collect all the capabilities and then to ask the business to relate capabilities to business objectives, or in other worlds to set which capabilities needed to support each one of the objectives. I'm doing this process to identify capabilities that are not related to any business objectives. Such capabilities, as far as I concern, should be retired. If a capability should retire all of IT assets, which support it, can be retire or reuse for other capability.

Whether I collect capabilities and map them to objectives or collect capabilities by objectives (ask which capabilities support given objectives) , In the end of this process I have an hierarchy of current goals, objectives and capabilities. Next task is to map between capabilities and IT assets that support them.

[AS-IS architecture]

This process helps to create the business "as-is", the question is how to create "to-be" architecture. Mapping the "to-be" business architecture also starts from business goals. This time I'm looking for new business goals that depict new business strategy. For example if the enterprise leadership decided to penetrate new markets, I would expect to see a new goal "Expanding into new markets". Each new goal has objectives to support it (for example “Trading Gas until mid 2011“ or “Operating another country energy market by the end of 2011“). Part of the objectives are new, and part of them are existing ones. Sometimes the "to-be" business strategy can only described by new objectives to serve existing goals.

[TO-BE Architecture]

Having the new goals and existing and new business objectives, I'm starting to find out if existing capabilities can be mapped to new objectives. As can be seen in the following figure, I'm using colors to define between new and existing capabilities. Any existing capability that support new objective, needed to be reviewed and validate that it can support the new objectives, be provided by existing role that perform it, etc'. Any new capability should be analyzed to define it non-functional attributes, which role should perform it, etc'. All of the goals, objectives and capabilities (existing and new), are the business "to-be" architecture (it goes without saying that I might add new roles, units, locations and any other business definition). The list of new goals, objectives and capabilities, as well as existing objectives and capabilities that support new goals or objectives are actually the gap between the as-is and the to-be business architecture.

[GAP]

Based on the collected data, I can compose a list of existing capabilities that support new objectives as well as new capabilities and start to work on it. Usually I'll make sure that IT assets that related to existing capabilities can keep on working in the same SLA, after they need to support new objectives. Secondly I'll look at the list of the new capabilities and try to figure out if existing IT assets can support them (and what is the impact on existing IT assets), or if new IT assets needed to be acquire or developed.

I hope that you manage to see how using business capabilities I can create new business architecture and then use capabilities to figure out what exactly are the impact of new Business architecture on the business as well as on IT.

Using captured EA assets to generate estimated project plan

2009-07-17T16:47:00Z

One of the tasks while doing EA is to collect relations between different enterprise assets (Roles, Units, Goals, Objectives, Business Capabilities, Information Objects, Entities, Applications, Products, Databases, Technologies, etc'). If the data already captured and maintained why won't we use it for a common task such as project estimation?

The above example is generated automatically from IBM System Architect. The user may drag and drop any IT assets and by using a macro generate all of the asset related building blocks (with lines that resemble the relation). Having all the related impacted or influenced building block on the diagram the user can enter, for each building block, estimated working days that needed to be done for the given change. The tool will generate automatically a project plane taking in account all of the related building blocks, the type of relations and man days assigned to each building block.

The results give you immediate estimation about the project duration. If you want you can go back to the diagram change durations or set two building blocks to be run in parallel, and rerun the macro to see how your changes impact the project duration.

Consolidation of CRM solutions

2009-07-13T13:46:00Z

Introduction

This white paper demonstrates and discusses solution for fragmented IT, which known as one of the classic IT problems. For demonstrating the problem and solution I chose to use a real life scenario of pharmaceutical IT department. After several acquisitions, following by IT merging, this department found itself operating and maintains three CRM solutions. The target of the described work was to decrease CRM Solutions to one solution. Minimize CRM solution expected to help IT department to decrease IT budget and complexity.

Problem Statement

After several M&A, the customer found himself using People Soft, SAP CRM and SalesForce.com. The Customer basic business units were using People Soft, while different acquired business units were using SAP CRM or SalesForce.com. The described situation caused significant complexity due to the need to integration between different IT solutions, and it also indicates an opportunity for cost reduction (at least for SAP and Oracle solutions). The client looked for a solution that will provide help with the process of deciding which solution should be remained and how to create a roadmap (with resources estimation) for such a project (Migrating from three CRM applications to one).

Previous Options

The client had several unsuccessful initiative with fragmented IT. All the previous initiative included bottom-up exercises, where data was collected from application owners and based on that data a decision has been taken. All of those initiative encouraged issues in implementation phase both from business side and IT side.

Proposed Solution

The Proposed solution was a combination of top-down, bottom-up approach. The solution took in account Business Capabilities, BPM, Business Process reengineering, IT integration needs, needed resources and costs. The described solution is based on Enterprise Architecture as a known and proven methodology to deal with different enterprise needs (Including the need to reduce costs).

Solution benefit: Top-down, Bottom-up approach

Top-down, bottom-up approach covered more areas of potential problems in implementation phase, thus minimize significantly implementation issues.

Solution benefit: taking in account business domain

Starting from the Business and touching business process management helped the client to get better understating of the business needs. Understanding the business helps to identify if IT solutions are duplicated, provided by one solution or not provided by any application. Dealing with business process management helped to adjust easily an IT solution to business capability and even to optimize the business process.

Solution benefit: Reuse

Using a tool helped the client to use the collected data of this work in other related enterprise architecture work that they have done after the described work.

Solution benefit: Based on proven methodology

Enterprise architecture is a proven methodology that was used successfully by different enterprises in different part of the world. This methodology is based on accumulative experience that was collected by many people and was used by me in different clients. Therefore using EA reduced pitfalls that one might encourage if he is trying to do such a work alone.

Implementation

The proposed implementation is based on three main steps:

1) Understanding what we have (As-Is).

2) Analyze data and decision making (To-Be).

3) Creating a road map and governance.

Understanding what we have:

In this step we followed the four enterprise architecture domains to understand the current CRM situation. We collected just needed architecture building blocks from Business, Information, Application and technology domains as well as the relevant relations between architecture building blocks.

This step is started from collection of relevant CRM business capabilities (Capabilities describe what the business is doing and not how the business is working) and current applications that involved in CRM work (Direct and supported or consumed application). Having business capabilities, we started an effort of mapping information flow between capabilities. We used the identified information entities to validate that all the relevant application collected, and all needed relations captured (this was done by relating each application to entity or entities)

We used the collected applications and Information as input to an exercise that looked for all the relevant technology assets (technologies, databases, servers, storage devices, etc’) that support both information and applications.

Based on business capabilities, Information and application we started to do mapping between application and business capabilities. This task assigned applications to business capabilities based on business user’s data. Note that we have just one business capability model, therefore several applications were mapped to one capability.

The reason behind using business capabilities (What and not How) for mapping as-is was to decrease the time needed for mapping current architecture.

We decided to use EA tool for this work. The tool helped us to finish mapping on time and served as time saver in next steps as well. The tool repository contained all collected data and relations, as well as at least one diagram per architecture domain. Main usage of the diagram was to communicate with different roles in IT and business.

Analyze data and decision making

This task was performed in three work steams in parallel:

1) Identifying relations between capabilities and applications:

a. Capabilities with more than one application to support them.

b. Capabilities with just one application to support then.

c. Capabilities without any current application to support them.

Using a matrix with applications and capabilities (on X and Y axis) we managed to see current applications support and understood which application provides more coverage to the client business needs. To get better picture if non supported capability could be supported by one of the CRM applications, we add this data to the matrix.

We used BPMN diagrams to model each business capability that had more than one supported application. A business process (how) helped to understand which application has better solution to the business need. If a business process helped to reach more accurate decision, we updated the described matrix.

A BPMN modeling was also used for each unsupported capability. This modeling was necessary to find out which one of the existing application support the capability and to what level.

While performing business process modeling, we also performed business process reengineering. Business reengineering helped us to adopt capability to an existing application or it contributed directly to capability improvement (without any relation to supported applications)

This task might perform complete business process modeling, but due to time constraint it was preformed just to describe capabilities (around 50%).

2) Identifying relations between supported capabilities applications and other applications

In this step each CRM application, which support capability, was assessed to understand integration to other applications and IT assets. This assessment counted interfaces of each application to other applications. The assessment took in account the direction, type of interface and data that flows. This data was taken in consideration when a decision was taken and for when we created the roadmap.

3) Based on collected technologies that support the discussed applications, we identified each application current IT costs. We’ve done the work by going through the list of related technologies for each application and collecting all the costs (Maintaining, supporting, licensing) for each technology. This exercise gave us relative estimation regarding the cost of each application.

When all of describes three work streams were finish, and based on collected and analyzed data, a decision regarding the chosen solution has been taken. The decision took in account costs, relations to other applications (amount of work needed to replace the solution) and coverage of CRM business capabilities.

Creating a road map and governance

Based on the analyzed data and the decision we started to create a roadmap, which took in account applications, needed to be replaced interfaces, change in data volume of applications, new supporting technologies, available resources and dependencies between different tasks.

Several alternative roadmaps were introduced to the client, and once the client chooses one alternative we helped him with governance. In other words, we helped the client to make sure that what was decided will be happened in reality

Summary

The described solution has been implemented together with the client within three months. It took us roughly two months to do the first step and one moth to do step two and three. We manage to reach clear cut decision regarding the CRM solution that will be implemented.

Creating IT strategy (with a little help from enterprise architecture)

2009-07-03T10:48:00Z

Creating IT strategy is one of the complicated task that I know. To create a good IT strategy, you have to use many ingredients from different types and sources. Those ingredients should be used in unique combination that can be cooked and then be served as a delicious Cake to different customers ( IT workers, IT management, Information workers, enterprise CxOs and sometimes the board). In this post I'll try to describe what, and who I manage to create an IT strategy.

Usually I tend to split my work into 6 main work streams:

Collecting as-is data
1. Mapping IT assets: collecting existing IT assets to understand what IT manage and to get a hint how.
  1. Information model: information entities and their relations. Helps to understand interaction between business units and level of integration from business perspective. Information model is also being used as an input to Information management.
  2. Applications and products : applications (internal development), External products and relations. Will be used for different aspects as well as mapping to core-context model.
  3. Technologies, Databases and servers : collect data about technical component and their relations. Used to understand what stand behind each application/product and to find out if resources are balanced (from usage point of view) and if new technologies (such as virtualization) are applicable.
  4. Communication infrastructures : same as technologies, but focused on communication.
  5. DRP : current design recovery plan.
  6. Information security : what procedures and IT assets are in place to support information security.
  7. Information from externals: what type of information the enterprise is getting from externals, in what format and how the data is being handled by the enterprise.
1. Information management: how information is manage, who own information, who use it, what is each information availability, etc'
2. Program of Work (POW) management : what is the current (if exists), how POW is being prepared, who is involved in this effort, what are the inputs for the process, is the POW address IT needs or just business needs, is it multiyear plan, is the plan enable prioritization and control, do we have milestones, deliverables and time tables, etc'
3. Budget management : who current budget is build (centralized or separated between business units), how the process is being done, who is involved, what are the inputs, is it multiyear budget, do we have breakdown of budget chapters, is the budget structure represent the major areas of expanses, is the structure enable management queries regarding budget behavior, Can we optimize budget without changing IT deliverables, etc'
4. IT equipment procurement management: are there any policies regarding procurement (Tender, predefined suppliers, how the process is done, where), what are the relations to other business units (when IT purchases), how IT physical assets are managed, any retire principles for IT equipment, etc'
5. Project management : is there one and uniform process for IT project, is the project follow PRINCE2, PMBOK or any other project management methodology.
6. IT infrastructure management (ITIL) : checking who much ITIL is implemented (even if its not ITIL explicitly) . Are we implementing any management of Incident, problem, configuration, release, change, capacity, financial, availability, continuity and service level.
7. Governance: mapping the IT against governance frameworks such as COBIT.
8. IT organizational structure and Human resources management. Existing structure and how it should support current tasks, one shop or shop per business unit, duplicated teams, location of teams in hierarchy, are teams located in the same physical location, compensation per role, etc'.
9. Training / Education : Current training and education plan or opportunities available, are they per role, are they address known gap in worker knowledge, are they related to POW, etc'
10. IT management - supporting forums: Are there any IT or enterprise wide forums that serve IT needs or IT is involved in, what is the perception of IT, is the CIO has CEO support, what is the CIO location in organization structure, etc'

Understand the business, future direction and who it impact IT
1. Business capabilities : what are the functions performed by the business to reach goals and objectives. Including new capabilities (or changes in capabilities) that support new business directions, or any business change. Used to see alignment between IT and business needs (current and future)
2. End-to-End business processes (Value chain): mapping main processes that generate value to the enterprise. Used to see interaction and integration between business units.

Understand new technology future IT directions and how they can Impact the business.
Create TO-BE architecture: Creating new architecture (blueprint or high level architecture) based on business directions, new technology options, key finding from IT assets mapping and IT as-is mapping.
Identify gaps between as-is and to-be: list all gaps in each element that we mapped in the "AS-IS"
Translate gaps into a roadmaps with dependencies and assignments : group gaps into projects, write one page of project high level analysis, assign resources to projects and creating a road map (taking in account dependencies )

Then I translate the work streams data into a word document with 6 main chapters:

Executive summary. Actually I'm writing different executive summary for each audience using relevant linkage to document paragraphs. I found out that although it's more work it proves to be more digestible. This way I can use different lingo and sharp different aspects of the strategy for each audience without rewriting the entire document and with ability for adjustments on the other hand.
Description of the as-is + to-be. Describe the data as it was collected from different roles. This part should hold just facts. I'm using it to build my findings on top of agreed facts.
Analysis : TO-BE based on analysis of collected data.
Blue-prints and Principles : based on the analysis what need to be done, and which principles should be followed by the enterprise.
Roadmap : Translate blueprints and principles into defined projects with assignments and dependencies with other projects and resources.

Enterprise Architecture Meta-model, size doesn't matter

2009-06-27T07:56:00Z

Part of the enterprise architecture work is to define a meta-model. Meta-model depict what are the architecture building blocks that we need to do our work, and their relations. Usually meta-model is one of the first task that we'll address in enterprise architecture work, following by collection of building block instances that we miss. There are many debates around enterprise architecture meta-model. Should I follow one provided by existing framework, should it be a complex or simple meta-model, what should be included in the meta-model and many other questions. In this article I'll try to address those questions.

The starting point in the journey to create your enterprise architecture meta-model is to understand important principles, which usually takes time to understand:

Enterprise architecture is about better managing Business and IT. It's not an attempt to understand internal technology, application, information and even business architecture. The best approach to reach a good meta-model is to depict in the meta-model dependencies between different enterprise building blocks as they exist in reality. Usually IT oriented guys try to follow application or technology architecture and impose it on EA, that doesn't work. For example depicting direct relations between application and servers is bad practice. Applications are using servers via databases, products or technologies that they are using.
Collect none exist data in the enterprise. For example if each application has internal application modules, don't add modules to your meta-model. Try to create a meta-model that will hold data and especially relations that aren't capture today (Keep building blocks that you want to capture their relations, but minimize attributes).
What you collect must be maintained. This principle is simple but for some reason many people don't follow it. If you'll have an impressive meta-model with 33 building blocks and 119 relations (see below) you're doomed to be failed. No way that over the time you'll manage to keep up-to-date all the data in such meta-model (Regretfully, you'll reach this conclusion just after years of EA experience). Without accurate data you won't be able to reach any success. I'm not talking about the human resources and governance procedures needed to keep such meta-model data up to date.
Metamodel can be developed in agile way. You can start from very small meta-model structure and enhanced it from EA task to EA task.

Those 4 meta-model principles are essential when you creating your EA meta-model, but the most important rule that you need to follow is that enterprise architecture meta-model should help you to do your work. Therefore the first effort in building a meta-model should be understanding what you want to reach in your EA, and if you're following an agile way of working, what you want to achieve in the next enterprise architecture task. Don't spend time to create a meta-model that will address all of your concern. Make sure that the meta-model support your next enterprise architecture work and enhanced the meta-model as your enterprise architecture become more mature. For example I managed to achieve amazing EA result from this simple meta-model:

Following the first, second and third principles keep your meta-model in the right granularity level. Don't fall into detailed architecture trap, but on the other hand keep any data that you need to do your work or to make you as a unique group in the enterprise. As I argue in my post about the death of EA frameworks, Finding the right granularity is something that you'll learn from experience, no framework will solve this puzzle for you.

In enterprise architecture meta-model domain, big in not better. Actually the other way around, small, lean and efficient is much more better than big and complex. You can test if your meta-model efficient by running EA scenarios and mark all the building blocks that you'll use. Any unmarked building block is "fat" that you want to take off.

Enterprise architecture frameworks are dead, long live real-life practice !

2009-06-21T13:27:00Z

I can remember the first time that I read TOGAF. I was really amazed from what I read. After spending time to understand Zachman framework, TOGAF looks like a mature and practical EA framework. Each paragraph that I read had a lot of sense and it looks like I just need this framework book on my desk to start an Enterprise Architecture journey. This was almost 10 years ago and before I had any enterprise architecture experience.

http://www.theeagroup.net/ea/Default.aspx?tabid=1&newsType=ArticleView&articleId=162

Enterprise architecture work Case studies

2009-06-05T09:00:00Z

After discussing how to use enterprise architecture for IT planning, reducing IT costs and M&A I had several request to share case studies that shows how the theory (which I already discussed) is used in reality. This post contain three case studies for IT planning, reducing IT costs and M&A. I hope you'll find it useful for your needs.

Using Enterprise Architecture for IT planning and increasing law and regulation Compliance

Client environment:
The client is an energy company that operates part of the energy market. The company’s got a 4 years license to operate from the government. To renew the license the company needs to demonstrate 1) full compliance to the relevant energy market laws and regulations. 2)99.9 percentage availability of the company services to the market energy. The company approaches us one year before license renewal to be able to present compliance and availability to the regulators.

Client business goals:

Show current compliance of company to laws and regulations

Show roadmap for filling gaps in compliance

Reach 99.9 percentage of availability from 99.5 (as it measured when the engagement started).

Approach:
We followed a modeling approach in order to capture current situation, identifying gaps and create migration plan (IT roadmap) to fulfill the above business goals in one year time frame. Using the models we manage to simplify the complexity of the enterprise business, information applications and technology domains and cross relations between those domains. Being able to reduce complexity significantly enable us to come with a conclusion and a roadmap within three months of work.

Steps:

Creation of meta-model of the data needed to be collected and relations (between data) based on existing reference model

Using existing data and collecting (interviews) missing data, while capturing all the data in one repository.

Mapping Business capabilities (or business functions) depicting compliance to laws and regulations.
Mapping needed information and how it comply to laws and regulations
Mapping applications and how they directly support business capabilities and information management requirements.
Mapping technologies (databases, servers, storage devices, technologies and communication) supporting applications and business capabilities.

Analyze the gap between the “to-be” (needed) state of the enterprise and the “as-is” (as found) state of the enterprise business, information, applications and technology domains.

Business capabilities without any IT support, or partly IT support.
Applications violating information requirements

For each identified gap creating migration plan to overcome the gap (preferred in one year, or at least to show that the company’s aware of the gap and going to fix it in the next 3 years)

Using modeled dependencies between business capabilities, information, Applications, databases, servers, storage devices, technologies and communication to increase IT availability.

Conclusion:
Following modeling approach of enterprise architecture and using existing IT assets documentation (CMDB, applications catalogue, Information modeling in Er-Win or any other tool) enable us to understand very easily and quickly, what are the gaps between the current situation and the business goals. We found out that 40% of the business capabilities are not supported or partly supported by IT assets. The work manages to show visually, by using a heat-map, where are those gaps. Following the heat-map, a migration plan was created to show how the gaps are going to be filled in the next three years. The relations and dependencies that were captured by the mapping work, used to better understand IT maintaining implications. This knowledge (which wasn’t available before) managed to increase IT availability to 99.9 percentage.

Using Enterprise Architecture for Decreasing IT costs while increasing IT availability

Client environment:
A governmental agency which provides a variety of vital 24*7 services to citizen, companies and other governmental agencies. The diversity of business services created an IT structure where each IT team is sole responsible for certain business domain, which created the typical silo IT structure. 5 years ago the clear boundaries between the agency business domains became vague, causing integration between IT teams. The demand for integration starts to prevent from the agency to achieve 24*7 availability of it services. On top of the integration problems and due to the economic situation the IT department needs to reduce 25% of its budget.

Client business goals:

To gain 24*7 availability of services while decreasing IT budget

To decrease IT budget without affecting availability of IT services

Approach:

We followed a modeling approach in order to capture dependencies and relations of current IT assets as well as their relations to the business domain in order to identify projects, application, technologies and servers that are redundant or may be retired in minimum impact and maximum budget reducing. The modeling approach also being used to understand cross relations between cross IT teams solutions increases IT services availability. Using the models we manage to simplify the complexity of the enterprise business, information applications and technology domains and cross relations between those domains. Being able to reduce complexity significantly enable us to come with conclusion and roadmap within three months of work.

Steps:

Creating meta-model of the data needed to be collected and relations (between data) based on existing reference model
Using existing data and collecting (interviews) missing data, while capturing all the data in one repository.
1. Mapping Business capabilities (or business functions)
2. Mapping applications, how they directly support business capabilities and information management requirements.
3. Mapping product (COTS), supported applications and business capabilities
4. Mapping technologies (databases, servers, storage devices, technologies and communication) supported applications, products and business capabilities.
Creating query mechanism that enable us to understand what all the IT assets are, as well as business capabilities, that will be affected if a given IT asset needs to be taken down for maintenance or any other purpose.
Looking for redundant IT assets
Looking for products or technology with high costs, low usage and minimum custom code, as candidates to be retired
Identifying high cost projects that don’t support directly core business capabilities
Analyze the data in order to create a roadmap of changes that will generate maximum saving without affecting core business capabilities.
creating migration plan, taking in account dependencies, to achieve cost reduction (preferred in one year, or at least to show that the company aware to the gap and going to fix it in the next 3 years)

Conclusion:
Following modeling approach of enterprise architecture and using existing IT assets documentation (CMDB, applications catalogue, Information modeling in Er-Win or any other tool) enable us to understand very easily and quickly, what can be retired and how. Our approach also enables us to quickly understand relations between cross IT teams assets, thus increasing significantly IT services availability. Using collected and analyzed data we manage to reduce technologies and products (mainly their licenses and support agreements) and redundant IT assets. Our work managed to save 3M$ per year and 7M$ for next year budget. A migration plan was created to show how the identified costs saving gaps are going to be filled in the next three years. The relations and dependencies that were captured by the mapping work, used to better understand IT maintaining implications.

Using Enterprise Architecture for Mergers and acquisitions planning

Client environment:
Our client is a High-tech Company with M&A (mergers and acquisitions) strategy as an enabler to become a leader in their field. Their strategy experienced many difficulties mainly due to different IT issues while dealing with M&A from IT perspective. Due to the fact that IT caused most of the issues, the IT was accused as a barrier to M&A.

Client business goals:

To be able to support M&A from IT perspective.

To raise difficulties in the negotiation phase, not in the implementation phase

Approach:
We followed a modeling approach in order to capture dependencies and relations of business and IT assets needed for acquisition from both business and IT perspective. We created two architecture maps to describe what’s needed from business and IT perspective when the company enters M&A process. We described the business domain, application, technologies and hardware architecture that if will be found in acquired company the merger from IT perspective will be transparent. Using those architecture maps and mappings of the acquired company IT we manage to understand in advance what the obstacles that we might encounter in a given acquisition.

Steps:

Creating meta-model of the data needed to be collected and relations (between data) based on existing reference model

Creating views that depict business and IT architecture of acquired company, which can be integrated without difficulties – “Best fits”

Mapping “candidate for acquisition” company by using metamodel and views.

Collecting existing documentation
Using interviews to collect missing data

Creating gap analysis between “best fits” architecture and current candidate to acquisition company architecture.

Analyzing the gaps to create roadmap for integration or to raise potential issues in the integration process from IT perspective.

Conclusion:
Within two months we managed to build architecture maps both for business IT perspective of M&A. those maps were built from 5 different views, 6 matrixes and 12 basic building blocks as well as principles and blueprints. Using this mapping we managed to find out in advance IT issues in two M&A, thus to change the attitude of the enterprise to IT and to assist two successful M&A.

Using Enterprise Architecture for forecast and implementation of Merges and Acquisitions (M&A)

2009-05-29T10:08:00Z

After explaining how to use enterprise architecture for IT long term planning and IT cost reduction this post is dedicated to enterprise architecture for merge and acquisitions (M&A). In this post I'll try to share with you my experience with how to use EA to forecast M&A efforts from IT point of view and after a decision has been taken, how to use EA to implement M&A (From IT point of view).

In a nutshell the idea here is simple (the implementation is not). Behind M&A we can find business logic, which can be transfer to business capabilities. And M&A strategy (Vertical, Horizontal, Concentric Diversification Merger and Conglomerate Merger), which can be translated to EA principles.

Based on business capabilities and EA principles we create an EA blueprint (or to-be architecture) which takes in account the needed business capabilities as well as information, applications and technology. If the combination of our and the acquired company "as-is" architecture meet the blueprint (supplying all the business needs and benefit from M&A) then the M&A should be easy and fast. We don't have such scenario in reality, but this blueprint serves as a model that we want to achieve.

Having this blueprint we can model each candidate (for acquisition) "as-is" situation. Then, based both on the blueprint and "As-Is" of both parties, we can Identify gaps and translate them to resources needed to fill those gaps. The outcome gives us indication how complex, aswell as resource and time consuming, a given M&A scenario will be. This outcome also sets the roadmap to M&A effort once decision will be taken.

Now let's see what are the tasks that we need to take in order to create the blue-print ("To-Be") and "As-Is" architecture, identifying gaps , translating gaps to resources and creating a roadmap for M&A. I'm writing from an assumption that your business, Information, Application and Technology domains are already modeled. If they are not you can follow my blog (www.theeagroup.net) to learn how to do it.

Creating blueprint ("To-Be")

First step is to understand which business capabilities are playing any role in the suggested M&A. We can find those business capabilities directly from our hierarchal capability model. or by going over business processes that should be effected from the M&A. note that we have to collect both business capabilities that will be effected and new business capabilities that we want to acquire through the M&A. the capabilities that we have to list down include also capabilities that will have any interaction with new capabilities that we want to acquire. To this pile we should also pour capabilities that we know that exist in both acquire and acquired, and we want to cancel one of those capabilities.

Having all the mentioned above capabilities (tagged as I mentioned), we can start to build end-to-end processes that depict the to-be architecture (post M&A situation). After understanding what are the impact from business point of view, we start to understand which Information (from your conceptual model) will be send and received (data flow) between capabilities in the to-be architecture. If it's an existing information we'll tag it as an existing, if it's an existing Information but we feel that a new entity should be added to this information, we'll tag it as well. If it's a new information, we'll tag it as well.

Next step is to understand which one of the existing application is playing in the game. For this purpose we're using a matrix. On the Y axis all the business capabilities and information that we manage to identify, on the X axis all the application (and products) that we have. We're using this matrix to map between an existing application to capability or information that is playing any role in the M&A. in a matter of fact most of this data already exist in our existing repository, we just have to do some adjustments following the identified new Business changes and new Information model. The outcome of this matrix is a list of applications that will be effected by the M&A, and which capability or information doesn't have any support using current application portfolio. If application support is missing we add new applications (tagged them as new) and relate them to existing applications (if data needs to flow between them or they need to consume a service, etc')

Now it’s time to start collecting data on technology stuck. Collect all the technology elements that will be effected by the listed applications, Information and business capabilities. Then start to build a to-be technology stuck by going through the common following topics:

Is there any new technology that can address new capability?
Is there a need to maintain new volume of data?
Is there a need for new security policies?
If there is a need for application integration, is the current technology sufficient?
Are there new applications required more CPU, Memory and storage? Do we have those resources?
Do we need to support new communication medium or new sites?

Again, tagged new, changed and existing technology elements.

Before building the "to-be" architecture we need to understand what is the M&A strategy (Vertical, Horizontal, Concentric Diversification Merger and Conglomerate Merger), since it influence the "to-be" architecture in a form of enterprise architecture principles.

Having all of this data in front of us, we can start to build (visually) the to-be architecture of the four domains.

Creating "As-Is" architecture:

creating the "to-be" architecture is pre-requisite . Next step is to map the "as-is" architecture of candidate company. The steps are more or less the same as modeling your own enterprise. You have to model business capabilities, information, applications and technology and their relations.

Identifying gaps:

Now the fun begin. We take the to-be architecture (blueprint) and both the as-is architecture of our company and the acquired company. I guess that the business capabilities that doesn't have any support in our organization are supported by the acquired company (otherwise, what's the point in acquiring them). For all the others architecture building blocks (information, application and technology) that was tagged as new, we identify if there are architecture building blocks in the acquired company that match them. If any new building block doesn't have a match in acquired company, mark them as gap.

Find out if existing building blocks in acquired company follow your architecture principles, if not mark it as a gap.

Using the technology architecture we find out if application in acquired company can work with our application collaboration platform, can it be integrated into security model, is it introduce new data volume that we don't have any support, is it using applications or technology that doesn't follow our Technical Reference Model (TRM), can we host the acquired company applications on your technology stuck, can our databases hold acquired company data, etc'. We add a new gap for each inconsistency that we find between the as-is of the acquired company and the to-be model.

We should finish with a list of gaps between the combination of our and the acquired company as-is and the to-be model that we defined. The gaps will give us an idea of how much complex this M&A from technical point of view. If you're using any EA tool you can see most of those gaps visually (see image 1.0). the less opacity building blocks are the “as-is“ building blocks.

Translate gaps to resources:

Gaps are not enough for understanding how complex a M&A will be from our point of view. Now it’s the time to use your and your team experience and translate those gaps into human and financial resources need to fill those gaps. Resources along are not enough to get a decision we need to add the time perspective as well. Therefore, for each gap the we manage to identify we'll have

human resources needed to fill the gap.
Financial recourses (without human costs) needed to fill the gap.
time estimation for filling the gap.

Next step is to take the gaps and trying to find out if they can be filled in sequence or in parallel. Then we can add the resources and time estimation and we'll have an idea not just how much it complex from technology point of view, but also is it feasible from practical point of view.

Creating roadmap for M&A:

If a decision to move forward with the suggested M&A has been taken, we need to translate the gaps into a road map. Actually most of the work already done, we know all the gaps, we know their dependencies and we have estimation of time and efforts needed. All we have to do is to break this data into a list of projects with clear outcome, described by high level analysis of the project, and a name of a person pulse his resources to do the project.

Using Enterprise Architecture to reduce IT costs ( a cookbook for IT cost reduction)

2009-05-22T05:35:00Z

In my post about "What can be done with Enterprise Architecture" I mentioned four main areas where I'm using successfully enterprise architecture. I already started to touch IT planning (will dedicate posts for M&A and BCP/DRP in the future) , So this time I want to deal with the hottest topic today : IT cost reduction.

There are six main directions that you can follow to reduce your IT costs. Each one of them required certain level of familiarity with your IT assets, business needs and available technologies in the market today. Those directions are:

Removing Unused assets. Removing or (reusing for other purpose) assets that doesn't support any business functionality (application, products, hardware).
Consolidation of servers, databases, technologies and applications.
Introduction of cost reduction technologies like virtualization, Grid computing, cloud computing, Etc'.
Freezing high cost low value projects, which will reduce HR costs and technology investment.
Replacing high cost low usage technologies, which will reduce licensing and support costs.
Changing agreements with suppliers to reduce cost (to 'site license' and from 'site license' to license by product)

As you can see each one of those direction required knowledge of what we (IT) have, our business environment and where we (Busines) heading. Therefore the first phase will be collecting this information by following a meta-model that suites your enterprise needs. The second phase will be modeling (or enter) the collected data into a tool that will enable you to view the collected data from different angles ( a business intelligence view of your IT assets and business direction). The third phase is running analysis on top of this data to gain success in each one of mentioned above direction. For example give in order technologies by four categories: performing the same technology capability, with the minimum application usage, that has minimum custom code written above the technology and with high cost. Our last step is to create a radmap (that takes in account current IT activities and dependencies) to set when and by whom the needed tasks will be performed.

Lets take a closer look at each one of those phases:

Collect and model. Collect architecture building blocks and model their relations. The most comon building blocks and relations for cost reduction are:
- Building Blocks
  - Business capabilities (name)
  - Applications (name, maintenance costs)
  - Technologies (name, description, cost – license + maintenance , number of maintaining persons)
  - Servers (name, cost)
  - Projects
- Relations
  - Capabilities to Applications
  - Applications to technologies
  - Technologies to Servers
  - Projects to business capabilities, application, technologies and servers.
Identify duplicate technology
- Execute technology report (technology name + technology description)
- Identify duplicate/overlap technologies by:
  - Organization knowledge
  - Using technology description
- Group duplicated/overlap technologies together
Validate conclusions
Calculate technology cost
- For each technology in each Group calculate technology cost
  - Licensing of software
  - Maintenance costs
  - Servers costs
  - Human resources costs
Identify Amount of Customizations
- find any custom code (usually mapped as applications) on top of each technology (to serve as infrastructure)
- Add the following data for each technology:
  - Amount of code that was written
    - Number of infrastructure applications
    - Number of lines of code
  - Amount of applications that are using custom code (on top of the technology)
Identify Usage & Business Support for Applications
- For each technology list all applications that directly using given technology
- For each technology you should have:
  - Application that are using it directly
  - Application the are using it indirectly (using custom code)
- For each application that is using one of the listed technologies get all business capabilities, which the application supports
- Add this list to each technology
Calculate Costs & Model Savings (incl. Cost to Retire)
- For each technology list:
  - Total cost
  - Amount of custom code
  - Application supported by custom code
  - Total application being supported by technology
  - List of business capabilities being supported by technology
- Identify if one of the given technologies required high costs, has less custom code, support less applications and support less business functions or less core business functions
- Find assets that dosen't support any business capabilities
- Look for technologies that fits into business enviroment and will reduce costs ( can't suggest cloud computing to CIA :-) )
- Identify the cost and time needed to convert applications, which are using the suggested (to be removed) technology, to work with the replacement technology
Create road map
- Create migration plan
  - For each application that requires a change
    - When the change will be done
    - What are the resources needed
    - Dependencies
  - When to retire the technology + Connection with vendor

IT cost reduction is not an east task from many aspects. Using enterprise architecture helps you at least in one aspect, it gives you systematic approach to deal with huge amount of data and possibilities. Such approach helps to reach better results in less time.

Natty Gur

What needed to be monitored to get better Governance

Communicate highly complex information to a broad audience

Related EA posts of mine

How to retire (respectfully) legacy systems

Using Hungarian Cube to demonstrate enterprise architecture

Information Architecture - The bridge between Business and IT

Business Capabilities and Business Strategy

Using captured EA assets to generate estimated project plan

Consolidation of CRM solutions

Introduction

Problem Statement

Previous Options

Proposed Solution

Solution benefit: Top-down, Bottom-up approach

Solution benefit: taking in account business domain

Solution benefit: Reuse

Solution benefit: Based on proven methodology

Implementation

Summary

Creating IT strategy (with a little help from enterprise architecture)

Enterprise Architecture Meta-model, size doesn't matter

Enterprise architecture frameworks are dead, long live real-life practice !

Enterprise architecture work Case studies

Using Enterprise Architecture for forecast and implementation of Merges and Acquisitions (M&A)

Using Enterprise Architecture to reduce IT costs ( a cookbook for IT cost reduction)