Subscribe: Natty Gur
http://weblogs.asp.net/ngur/Rss.aspx
Preview: Natty Gur

Natty Gur



Enterprise Architect on Enterprise Architecture



 



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

Mon, 21 Mar 2011 12:19:00 GMT

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.

(image)

Read ...




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

Wed, 09 Mar 2011 01:49:00 GMT

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)

(image) (image)




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

Fri, 25 Feb 2011 03:01:00 GMT

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)

Fri, 18 Feb 2011 16:41:00 GMT

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

(image)

(image)

Read more




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

Sun, 21 Feb 2010 14:18:00 GMT

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]
 

(image)



Real Example of Enterprise Architecture Values

Sun, 14 Feb 2010 14:04:00 GMT

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

Sun, 07 Feb 2010 13:53:00 GMT

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

Tue, 10 Nov 2009 23:11:00 GMT

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 Informati[...]



What needed to be monitored to get better Governance

Fri, 23 Oct 2009 11:42:00 GMT

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 archite[...]



Communicate highly complex information to a broad audience

Sun, 27 Sep 2009 10:39:00 GMT

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. T[...]



Related EA posts of mine

Thu, 17 Sep 2009 13:47:00 GMT

How to retire (respectfully) legacy systems Information Architecture - The bridge between Business and IT Business Capabilities and Business Strategy Consolidation of CRM solutions Creating IT strategy (with a little help from enterprise architecture) Enterprise Architecture Meta-model, size doesn't matter Enterprise architecture work Case studies Using Enterprise Architecture for forecast and implementation of Merges and Acquisition(M&A) Using Enterprise Architecture to reduce IT costs ( a cookbook for IT cost reduction) Business Capabilities (a practical guide) Using enterprise architecture for creating long term IT planning (roadmaps) What can be done with enterprise architecture Principles as enterprise architecture outcome blueprint - an enterprise architecture outcome How to build practical enterprise architecture team Modeling application dependencies Can enterprise architects be young? Using Hungarian Cube to demonstrate enterprise architecture Enterprise architecture frameworks are dead, long live real-life practice ! IT('s) Simple! How to do inormation architecture (in 20 days) What really makes you Enterprise Architect Information Architecture (What need to be collected and modeled) Information Architecture (What is information architecture) Enterprise Architecture in SAP world Sorting SA diagrams by EA domain Reference model for EA definitions and views What I expect from a vendor EA framework Business concept Worktures It's not SOA it's IT 2.0 10 standards (including standard de facto) that Enterprise Architect should know Proven way to run your Enterprise Architecture practice The triangle of complexity and the square of success for EA projects What is a service (part II) How to publish your EA work SOA implementation types, from the Chinese city to the European city What is a Service The utopia of one dictionary for the enterprise How your IT chassis will look like - Part 1 Are your IT vehicles based on one chassis? Enterprise architecture modeling example Enterprise architecture is just another systematic approach SOA, It’s not about the IT It’s about the Business. Business capabilities or business processes The Data-Centric Enterprise: A Blueprint for EA - Listen to the audio and watch the - slides! (Running time: 59 minutes) Does enterprise architecture serve only for long term strategic plans? Introducing NAAF. Using enterprise architecture framework to map services and set their granularity The “Natty” method for monitoring and encouraging systems compliance with the - enterprise architecture What are Enterprise architecture patterns and how we should define them? Enterprise architecture 10 common myths [...]



How to retire (respectfully) legacy systems

Fri, 11 Sep 2009 07:10:00 GMT

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:

  1. 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'
  2. Discussion: a formal discussion to approve the system retirement with participant from all relevant organization units (following the mapping)
  3. 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.
  4. 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.
  5. 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

Sat, 08 Aug 2009 10:10:00 GMT

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!

(image)

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.

(image)




Information Architecture - The bridge between Business and IT

Mon, 03 Aug 2009 12:24:00 GMT

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 i[...]



Business Capabilities and Business Strategy

Sun, 26 Jul 2009 13:22:00 GMT

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][...]



Using captured EA assets to generate estimated project plan

Fri, 17 Jul 2009 16:47:00 GMT

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?

(image)

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

Mon, 13 Jul 2009 13:46:00 GMT

  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: [...]



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

Fri, 03 Jul 2009 10:48:00 GMT

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 Mapping IT assets: collecting existing IT assets to understand what IT manage and to get a hint how. 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. Applications and products : applications (internal development), External products and relations. Will be used for different aspects as well as mapping to core-context model. 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. Communication infrastructures : same as technologies, but focused on communication. DRP : current design recovery plan. Information security : what procedures and IT assets are in place to support information security. 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. Information management: how information is manage, who own information, who use it, what is each information availability, etc' 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' 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' 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'  Project management : is there one and uniform process for IT project, is the project follow PRINCE2, PMBOK or any other project management methodology. 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. Governance: mapping the IT against governance frameworks such as COBIT. IT organizational structure and Human resources management. Existing structure and how it should support current task[...]



Enterprise Architecture Meta-model, size doesn't matter

Sat, 27 Jun 2009 07:56:00 GMT

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 [...]



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

Sun, 21 Jun 2009 13:27:00 GMT

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