Natty Gur

The Enterprise Architect (EA) diary - Day 34-36 (Information Architecture)

2011-03-21T12:19:00Z

Although enterprise architecture consider to be based on four domains (Business, Information, Applications and technology) for me the business and information domains are more important to become successful enterprise architect. There aren’t any doubts about the need to understand what is driving the business and what and how the business is reaching (and planning to reach) it strategy. Business architecture is crucial to make sure that IT is really supporting and planned to increase IT’s business support. Information architecture, which is critical for EA success is usually hide as sub domain of application architecture or doesn’t get the right attitude and resources.

Read ...

The Enterprise Architect (EA) diary - Day 25-32 (Modeling & decentralized organization)

2011-03-09T01:49:00Z

The Enterprise Architect (EA) diary - Day 25-32 (Modeling & decentralized organization)

Working for company with different business units locating in different places around the world requires me to pay visits to our offices. In the last 6 days I paid a visit to our office in London and Manchester area (which belong to different business unit). The trip has two goals: to model changes in those offices current architecture and to reach an agreement regarding our target architecture (using the same principles and blueprints)

The Enterprise Architect (EA) diary - day 22 (from business processes to implemented applications)

2011-02-25T03:01:00Z

After spending time on keeping our repository up to date (add new ETRM application and related data flows as well as changing databases to DB clusters), collecting more data for the root cause analysis and spending time for writing proposal to creating new software infrastructure team ( that will help us to clean the table from a pile of problems that just keep on growing due to BAU control over IT dev team resources). I spend time to adapt our EA tool to support a diagram flow from high level business processes to implementation of new applications that will better support the business process. http://www.theeagroup.net/ea/Default.aspx?tabid=1&newsType=ArticleView&articleId=195

The Enterprise Architect (EA) diary - day 15-20 (IT architecture)

2011-02-18T16:41:00Z

We’re working on IT architecture or more accurate to-be architecture for very long time. After we spend time to model and understand what IT has to offer as well as what the business is doing (and need) to reach company’s goals and objectives, we started to work on the to-be architecture in two phases.

Phase 1	Phase 2

Plan your budget and reduce risks by aligning enterprise products road maps to the vendor road maps.

2010-02-21T14:18:00Z

Vendors tend to publish roadmaps for their products. Those roadmaps include when the product schedule to be replaced with new version, when the product regular support will be replaced with extended support and when the vendor won’t support certain product version.

Capturing this data is important for several needs. We don’t want to find our self having a problem with a product that doesn’t have any vendor support (especially if this product support core business capabilities), and we want to minimize (as much as possible) costs associated with extended vendor support.

It’s a tedious process to collect relevant vendor information, maintain it and compare it to enterprise roadmaps for each vendor products. But as anything else in life, analyzes this tedious work outputs tend to produce insights that can be translated to EA achievement. We can identify in advance if we are going to enter extended support contract or if we are going to use unsupported product next year. Identifying those issue in advance enable us to plan and therefore to reduce costs and risks.

I always like the visual approach; therefore I translate the collected data into visual presentation where I can see on a time scale how vendor products roadmaps are related to my enterprise roadmap. You can see below a real life example of compression of MS products. The top row represents Microsoft roadmap, while the second row represents my enterprise roadmap (for the same project). This example is limited to product availability, but it can be extended with extra support easily.

[Click image to get XLS file - Original post]

Real Example of Enterprise Architecture Values

2010-02-14T14:04:00Z

This time I'm sharing a list of EA values of mature EA practice. This customer is a leading company in the utilities industry with aggressive business strategy of merge and acquisition. as a result they have continues challenge of merging IT units together.

Creating one common language across IT units
- Each term is currently used with several meanings, for example the terms system, technology, application and even hardware are being use to describe the same architecture definition across IT units
- Creating System and technology architecture based on an EA approach will provide XXX one common language with clear definitions will minimize confusions in terms usage
Impact analysis through data and meta-model
- Data exist in silos (Excel Sheets) without any connections between different definitions in different silos. In additional to the fact that terminology is inconsistent, data is stored in many excel sheets with no linkages.
- Following an EA approach data are collected and related to other relevant data (as defined in EA meta-model) and enable better impact analysis scenarios based on the existing EA definitions, attributes and relationships. This approach will replace the today need to prepare data for each new impact analysis.
Architecture for agility
- Using best practice definitions to conceptually split monolithic systems into set of components improve reusability and flexibility. Instead of treating IT assets as systems, EA suggest breaking systems into applications, technologies and (as indirect linkage) servers and hardware.
- This approach clearly creates boundaries between Business Applications (custom code to support internal business needs), Technology (purchased software to support the business application) and Server/Hardware. By building these "layers" using services, a change/replacement of a layer is much simpler. This type of IT conceptualization provides more agility especially when all relationships recorded can be queried by XXX IT teams.
Alignment to business
- Using the suggested EA approach, Applications and Technology (with or without Services) are related to specific business function that they support.
- This enables the enterprise to see which business function(s) is supported/not supported by IT. Using this data, a long term IT planning can be created to improve IT to Business alignment as well as communications between IT and Business.
Services as a better way to increase reusability and flexibility
- Services are any predefined endpoints that provide predefine functionality with known inputs and outputs. From the EA meta-model point of view services can be provide in different protocols (API, COM interface, Java/.Net interfaces, IPC, FTP, Web Services, etc').
- The proposed EA meta-model suggests using services for technology and applications to simply enable us to expose functionalities that are consumable from applications and technologies that exist currently.

Case study of not successful EA practice

2010-02-07T13:53:00Z

After posting three case studies of successful enterprise architecture practices and discussing common EA pitfalls I decided that it’s the time to present a case study of en enterprise architecture practice that didn’t manage end up successfully.

Using Enterprise Architecture for changing business processes

Client environment:
The client is a government agency heavily based on information and information management for reaching the agency goals and objectives as they set by the regulator. This client new CEO came with new agenda of how the business need to be done in different and more affective manner. The CEO understands that the best way to enforce his new strategy is by changing IT business applications, systems and technology. To make his vision a reality the CEO asked the CIO to start a group that will make the change in current IT landscape.

Client business goals:

Translate CEO vision to practical business capabilities and processes
Change IT landscape to support new CEO vision
Successfully implement new system to facilitate CEO vision

Approach:
the team 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. The work has been done internally in the group without interaction with IT teams with a goal to present migration plan after 12 months.

Steps:

Translating CEO vision into new set of business capabilities and processes. Using business capabilities to create hierarchal structure of business functionality and by using BPMN describe how those capabilities are being done.
Analyzing gaps between current and future business architecture. Understating new capabilities, how business processes are going to be changed and identify new business processes.
Mapping current IT assets and modeling conceptual and logical models for Information, Applications and technologies (including hardware).
Mapping existing IT assets to existing business capabilities.
Based on current IT architecture and new business architecture creating future IT architecture by setting principles, standards, blueprints as well as conceptual and logical models of future Information, Application and Technology domains. The future IT architecture should cover all business capabilities exist in future capabilities map (at least all of the core capabilities).
Analyzing gaps between current and future IT architecture.
Identify opportunities for each gap and select the best solution.
Translate the selected solution into 3 years roadmap.
Present the work to CEO and IT.
Get CEO support but reluctant approach from IT to adopt the plan.

Conclusion:

although the practice manage to understand new business direction and even get the CEO approve, the practice failed due to the fact that IT didn’t cooperate with the suggested roadmap. The reason for this failure is deeply rooted in the way that the EA work has been done. Doing EA from ivory tower without deep involvement of the people that need to do the work eventually, result in resistant from implementation level and actually caused a failure (regardless if the suggested architecture was the right or wrong one).

10 EA pitfalls that a real EA implementation might experience

2009-11-10T23:11:00Z

Doing EA just for the sake of EA: Enterprise architecture is a mean to reach a goal. If you don’t know what is your goal and how you'll use enterprise architecture to reach this goal, you fall into the most common and painful pitfall. There should be at least one goal; like to reduce IT cost, better planning and executing of IT, dealing with compliance requirements or even migrating legacy applications to new platform. If you cant provide clear goals and explain how EA is serving you, you're doing enterprise architecture for the sake of enterprise architecture. Regretfully doing EA for the sake of EA will bring your initiative to complete failure.
Weak political skills of EA lead: I once wanted to write an article about "The election of new enterprise architecture" :-), I might do it in the future. Doing enterprise architecture is usually involved in many changes that enterprises need to go through. Changes from any types are not easy to digest by employees. In order to introduce and implement a change one need to be a real political animal to survive in the jungle and make the jungle a better place. If the enterprise architecture team leader is missing political skills, the project is also doomed to be failed.
No measuring and selling of EA: as any thing else that we are doing in life we need to make sure that other people understand the importance and contribution of enterprise architecture to the enterprise. It's not enough that we as a team are very happy and the CIO is happy as well. We need the entire enterprise to understand what is our contribution. To sell our enterprise architecture work we need to put some efforts in collecting data and measuring what is the enterprise architecture contribution. For example if we were after IT cost reduction as a goal, we want to show how much money on time scale we managed to save to the enterprise and how much money we'll save in the future.
Lack of short term outcomes : long enterprise architecture projects without any deliverables tend to fail as well. The scenario is pretty known. We got a charter to start EA work and we were told that we have a year to do our work and show what we've done. But funny enough, the same guy that told us to work for a year will loose his patience if he won't show any deliverables after three months. So if the scenario is known why not to prevent it. Simply plan for deliverables every three months and reduce pressure from you.
Not enough involvement in SDLC: creating to-be architecture together with principles, standards and blueprints is huge step forward, but without making sure that what you set will be done in reality (to some degree) you simply will lost it all (or it will be equivalant to the chiness great leap forward). In order to make sure that you will affect IT landscape you need to be fully involve in running projects. When I say involvement I don't mean formal reviews as part of the SDLC. What needed here is actual participant in SDLC. You should be with the working teams to know when EA principles clashing with project needs and timelines to be able to influence. Finding that a project is not compliance at all to enterprise architecture when formal code review is done, is too late. If the project approved by clients it will be deployed no matter if it compliance to EA or not.
Missing focus on Information: there are two main types of focus while doing EA project. It can be business focus or Application/Technology focus. Few EA initiative that I know are focus on information. Whether you like it or not information is the bridge between business and IT. Business can't perform business processes without information (as input/output to each processes task) and IT helps to manage Information and manage processes. Most of the basic problems that I found in enterprises have roots in Information management. If Information isn't manage correctly I bet that you'll find problems in business processes as well as in application domain. Focusing on information will not make your EA success or failure, but it will certainly helps you to achieve success.
Buried under business processes: people tend to think that modeling all enterprise processes is a good practice. It might be right, but they forget about much more difficult task, which is keeping business processes up to date. I found out that using business capabilities mapping (just what, not how) I have enough data to do my work. Usually I found myself modeling high level business processes, but I never end up with detailed modeling of all business processes.
Missing PMO / Finance control: getting CEO/CIO or any executive support is nice but not enough. If you want your enterprise architecture to be successful you got to have teeth that can bite. If you don't have teeth you'll find yourself spending a lot of time to get the same thing that you can get much more easily with teeth. The most powerful set of teeth that I know is your ability to control financial or PMO duties. So if you don’t have any PMO/Financial control, try to get them ASAP.
Wrong location in hierarchy: never underestimate your group location in the enterprise hierarchy. People might say that it doesn't make any different, but there is a huge different if your team directly under the CEO/CIO or the team reports to director which reports to a VP that reports to a VP and the VP reports to the CIO. Again support is not enough , your location in the hierarchy does matter.
Spending time on frameworks: well, I make my living from creating frameworks for enterprises, but I believe that it's a waste of time. Don't waste months to create a framework based on TOGAF, Zachman, FEAF or any other framework. Find a pain-point and use your common sense (or consultant experience) to resolve the pain-point using enterprise architecture. Don't worry you'll build your EA framework one way or another, just following my approach you'll get success and credit that are needed as well.

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.

Natty Gur

The Enterprise Architect (EA) diary - Day 34-36 (Information Architecture)

The Enterprise Architect (EA) diary - Day 25-32 (Modeling & decentralized organization)

The Enterprise Architect (EA) diary - day 22 (from business processes to implemented applications)

The Enterprise Architect (EA) diary - day 15-20 (IT architecture)

Plan your budget and reduce risks by aligning enterprise products road maps to the vendor road maps.

Real Example of Enterprise Architecture Values

Case study of not successful EA practice

10 EA pitfalls that a real EA implementation might experience

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