Natty Gur

Enterprise Architect on Enterprise Architecture

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

    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)

    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)

    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.


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

    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

    Read more


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

    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

    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.


    1. 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
    2. 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.
    3. 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.
    4. 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.
    5. 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

    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:

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

    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.


    1. 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.
    2. Analyzing gaps between current and future business architecture. Understating new capabilities, how business processes are going to be changed and identify new business processes.
    3. Mapping current IT assets and modeling conceptual and logical models for Information, Applications and technologies (including hardware).
    4. Mapping existing IT assets to existing business capabilities.
    5. 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).
    6. Analyzing gaps between current and future IT architecture.
    7. Identify opportunities for each gap and select the best solution.
    8. Translate the selected solution into 3 years roadmap.
    9. Present the work to CEO and IT.
    10. Get CEO support but reluctant approach from IT to adopt the plan.


    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

    1. 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. 
    2. 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.
    3. 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.
    4. 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. 
    5. 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. 
    6. 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.
    7. 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.
    8. 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. 
    9. 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.
    10. 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

    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

    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.