Natty Gur

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

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

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

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

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

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

Enterprise Architecture Meta-model, size doesn't matter

nattYGUR — 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 frameworks, Finding the right granularity is something that you'll learn from experience, no framework will solve this puzzle for you.

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

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

nattYGUR — 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

Enterprise architecture work Case studies

nattYGUR — Fri, 05 Jun 2009 09:00:00 GMT

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

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

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

Client business goals:

Show current compliance of company to laws and regulations

Show roadmap for filling gaps in compliance

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

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

Steps:

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

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

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

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

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

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

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

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

Using Enterprise Architecture for Decreasing IT costs while increasing IT availability

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

Client business goals:

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

To decrease IT budget without affecting availability of IT services

Approach:

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

Steps:

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

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

Using Enterprise Architecture for Mergers and acquisitions planning

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

Client business goals:

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

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

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

Steps:

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

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

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

Collecting existing documentation
Using interviews to collect missing data

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

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

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

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

nattYGUR — Fri, 29 May 2009 10:08:00 GMT

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

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

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

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

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

Creating blueprint ("To-Be")

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

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

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

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

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

Again, tagged new, changed and existing technology elements.

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

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

Creating "As-Is" architecture:

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

Identifying gaps:

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

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

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

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

Translate gaps to resources:

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

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

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

Creating roadmap for M&A:

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

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

nattYGUR — Fri, 22 May 2009 05:35:00 GMT

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

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

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

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

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

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

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

How to create and use business capabilities - The poster

nattYGUR — Fri, 15 May 2009 06:08:00 GMT

After explaining how to create and use business capabilities in my previous posts I'm proud to share with you a poster that takes all the main steps, and their sequence, to create and use business capabilities for different needs.

(click the image to download a PDF file)

In my next posts I'll address in more details how to use business capabilities for each one of the scenarios in the poster.

I hope that you'll find this poster useful,

Natty Gur.

Business Capabilities (a practical guide)

nattYGUR — Fri, 08 May 2009 08:01:00 GMT

In my last post about using enterprise architecture to create long term IT planning, I argue that business capabilities are crucial for this work but I didn't explain in details what are business capabilities and what need to be done to collect and model them. As I promised this post is dedicated to business capabilities.

First of all let me explain what are business capabilities (at least as I see them). Business capabilities describe WHAT the business is doing to reach the business goals and objectives. Each business capability should have an input and it must generate value to the business. Although business capabilities can be used in business processes that describe HOW the business is doing daily work, business capabilities never deal with HOW (just WHAT). Each business capability might have corresponding business process that describes how the capability being done (people, data, events, decision points, capabilities and relations between all mentioned elements)

I tend to order business capabilities in hierarchal manner, starting form high level business functions and breaking them to low level functions. Some people tend to break business capabilities by organization structure. Although this is very convenient and easy way, it creates a twisted view of the business capabilities (usually because capabilities are cross organization). In an hierarchal view of business capabilities low level capabilities could be duplicated and exist in several high level capabilities (Sometimes this scenario is bad sometimes it good).

[figure 1 - Business Capabilities map]

Business capabilities are a way to model your business, but they are also one of the best way that I know to bridge between business and information technologies. To create the bridge we simply use business capabilities as a hook that we want to hang on all of the IT assets that we have (as you can see in the below figure).

[Figure 2 - EA meta model]

In addition to hooking capabilities to IT assets we keep certain amount of properties for each capability. Keeping many properties might be very impressive, but always remember that you need to maintain the data that you entered as well. The trick here is to understand what it the purpose of your enterprise architecture work and to collect just the needed data for this propose.

Common usage of business capabilities:

Create alignment between Business and IT
Enable creation of business oriented IT roadmaps
A tool that helps business improvement efforts
Services identification
What are the services that the business need
- In the right level of granularity
- To enable business agility
- To be implement by IT

Validation of vendor’s packages to business needs

A common list of properties that I'm usually using:

Name
Description
Used by
Owned by
Input (data)
Output (data)
Availability
Response Time
Reference to documents (plus relevant paragraph)
In service date
Childs (BC)

One of biggest advantage of business capabilities is that they required much less resources and effort to maintain, while bringing the same ROI for enterprise architecture as business processes will generate. Focusing on the what reduce significantly the amount of resources needed to maintain them.

Business capabilities effort can be spitted into 5 main steps:

Initial collection of dada. Collect all the data that you can by yourself and try to build first version of the business capabilities map and use it in the next step. The most common resources that you can get to build the map are:
- Job Description
- Internal procedures
- Business Reference Models
  - SCOR
  - VCOR
  - SAP Business scenarios

Interviews. After you have some starting point as a reference, start to interview business users to validate and change the map. This is iterative process that might take some time and usually involved usage of your soft skills.
- Don’t come to interviews with empty hands! Use collected data to create initial model. Use them to facilitated interviews
  - Use Nylon cover and camera to take interviewees comments and compare them
- Valid and augment initial map

[figure 3 - Using capabilities map in an interview]

Formal approve (By Biz management). If you can get CxO level approve you are on the right path to success. If not try to get any high level management approve, just make sure that business management participant.
Relate IT to Business Capabilities. I already discuss it in my previous post. Ask business users to set what are the IT resources that they are using to carry on capability and to what extent IT assets are helping them. IT assets should include:
- Application
- Technology
- Services

Relate business capabilities to Business objectives. While low level capabilities mapped to IT, high level should be mapped to business objectives. Relating capabilities to business objectives will help us to understand what is the Wight of each capability from business point of view.

Useful tips (or what I learned from mistakes :-) ):

Don’t use one big bang approach, Do it in phases!
Always work on two levels of hierarchies. While going through the interview process, lower level capabilities helps (both you and the interviewee) to understand higher capabilities.
Get agreement on capabilities before defining capabilities attributes. Collecting capabilities attributes is a process which takes time. Don't invest this time until you sure that you have a list of the agreed capabilities.
5-6 level of hierarchies are magic number where all of my clients stop. It doesn't matter the client size or location, we always stop in this level. The granularity of Level 5-6 enable us to hang several applications on each capability. In Higher level you'll find yourself hanging tens of applications on each capability. In lower level you'll find yourself drown in tones of details.
Start from the first two high level. Then focus on one of the second level capabilities and drill down to the 5-6 level.
Face to face or group approach: I found out that face to face is much better. Face to face reduce the "I need to show how smart I am" syndrome, thus reducing the time it takes to reach common understanding and agreement.
Don’t fall into the organization structure trap. Follow roles, not their location in the organization structure.
Each capability name should be a combination of one Verb and one Noun.
Each capability should have different combination of functionality, input and business value as outcome.
Use an EA tool to do the mapping. Tool has many advantage such:
- One place to see all architecture components and relations between them
- Ability to run impact analysis scenarios
- Ability to run “What-If” scenarios
- Use reporting (textual, hit-map, etc’)
- Integrate capabilities with SDLC

Business capabilities are very powerful both for business, information, applications and technology architecture. Once you went through the process of collecting them you have an important asset that will serve you as enterprise architect in most of your tasks. Business capabilities won't just help you in your tasks they will also give you much more time to do your work, because they demand much less resources for maintenance (if you looking for an analogy, business process are like dogs while business capabilities are like cats).

Using enterprise architecture for creating long term IT planning (roadmaps)

nattYGUR — Fri, 01 May 2009 13:51:00 GMT

There are many aspects that we need to address when creating IT roadmaps such as better business support, replacing old and not supported technologies/products/applications, strengthening ( new servers, storage, licenses, databases, etc' to support IT in the next 3/5 years) and more. In this post I'll try to focus on planning IT for better business support.

In order to do this task we need to collect data about enterprise business capabilities (will be addressed with examples in my next post), applications, products, databases and technologies as well as the relations between them. Relations should describe which applications and products support business capabilities as well as databases and technologies (including server and storage) that support applications/products.

Stage 1 : Business capabilities and what we are missing from business point of view

We start with modeling of business capabilities and existing application and products. Then when we have all capabilities, applications and products we ask our business user to define which application / product they are using for each capability and what is the percentage which they believe that the IT asset help them to do the work. When this work is done, we have a list of application/products attached to each capability that the users believe it has an IT support. If the users believe that IT fully support a given capability the sum of all the supporting assets percentage will be 100 percent (each IT asset might have different percentage reflecting different weight / satisfaction as seen by users).

Using this data we creating a heat-map view of business capabilities. The heat-map depicts in red, yellow and green if a capability has none, partly or full IT support. This view give us an impression where there are areas in the business that doesn't have any IT support or are not fully supported by IT. This view is also created in an excel report, which shows for each capability, supported IT assets and the percentage of each one of the supporting IT assets.

Having this data we can start to realize what are the business areas that we need to cover in order to better support the business. First we are looking for capabilities that has many unsupported instances in the map. Creating IT solutions for those capabilities will generate more impact from IT point of view. Following the mention above capabilities we order unsupported capabilities on the basis of core and context capabilities.

Step 2 : IT assets and what can be done from IT point of view to provide better support

Having a list of all (the supporting business capabilities) applications and products we start to map what are the databases, technologies, servers, data storage etc' that those applications are using. This data also include ( as properties) what is the cost of each one of the IT assets, how old is the technology, when support is going to be expired, etc'.

We are using this data for three main purposes:

Finding out if we can use current assets to support gap in business support: for each gap in the business capability heat-map (partial support or not supported) we try to identify if an existing IT assets might provide support and what will be the cost of this support. We add this data as another dimension to the list of business capabilities with gap in IT support (the list that was mentioned in step 2 ), so mow we know the cost of each proposed solution using existing assets.
Find old technology or product that could cause problems and harm business capabilities that already have support. A capability might have perfect support from the user point of view, but from IT point of view the capability might experience issues due to the fact that the IT solution is based on old or unsupported technology/product. To ensure better IT support to the business we want to handle such scenarios and to replace the old/unsupported technology/product. The output of this work stream is a list of technologies/product that needed to be replace in the next 3/5 years as well as the impact of those changes on other IT assets.
What are the impact of new technologies, applications and products. For each gap in capability support that doesn't have any solution by using current IT assets we try to identify new technologies / products or new home developed applications that could help IT to fill the gap. For each one of the new proposed IT assets we indentify costs, dependencies and impact on current and new IT assets. We are using the described information to add it as another dimension for each (not fully supported) capability, similar as described in the first purpose.

Step 3 : creating the roadmap

In the end of phase 2 we have a list of proposed solutions for filling gaps in capabilities support and to prevent issues in capability operation. Now we need to take in account existing projects, any type of dependencies and resources (budget, human) to create a roadmap. In this step we try to come up with a road map that will have maximum effect, support of core capabilities and will be able to execute from resources and dependencies point of view.

What can be done with Enterprise Architecture

nattYGUR — Fri, 24 Apr 2009 06:20:00 GMT

In my own opinion enterprise architecture is not just a high level strategic planning of the enterprise ( well lets face it, the IT in the enterprise). I see enterprise architecture as a proven, consistent and reusable way of doing IT task that we are already doing any way for years. Yes, it's also serves us for high level planning, but it also (and most of the time) serves us for our daily tactical IT tasks. It goes without saying that enterprise architecture also accompany not just the decision making, but also the actual work that will be taken to make those decision a reality.

In order to do enterprise architecture work in more consistence way, I tend to collect all the existing assets of my organization and the relations between them. The collection work comes hand in hand with modeling work which depict what has been collected and the insight that we manage to gain. We collect data from business, Information, Applications and technology domains of the enterprise. In order to do enterprise architecture work reusable, I'm using an EA tools (No matter which one of them as long it comes with a repository).

Collection and modeling is a tedious step but it's crucial for success. I address it several times before, but I'll say it again: it actually create a unique knowledge which makes my a subject matter expert in the enterprise. The collected and modeled data enable us to massage and analyze collected data, yielding new insights that will help us in our daily tasks.

The question is, what are the tasks that EA can help us to do better? I tend to split those tasks to four main domains:

IT planning. This domain contains any planning such as creation of 5 years IT road maps ( align IT to business), dealing with BCP (business continuity planning) and DRP (Disaster recovery planning), planning for M&A ( Merge and acquisitions) , Adopting new technology such as cloud computing ,integrating new technology, etc'
IT cost reduction. This domain is focused on how to reduce IT costs by elimination of duplicate IT assets, adoption of new technologies/architectures, finding redundant IT assets, halting cost demand projects with less business contribution then other projects, retire high cost technologies, reduce IT complexity, etc'
Increase Compliance. This domain is all about increasing compliance by taking advantage of what IT has to offer. Whenever it's technology, architecture or simply a principle or a blueprint that will guide or directly increase compliance.
IT optimization. In this domain we are using enterprise architecture to increase up time of IT services and reduce the duration of time for analyzing, designing and developing new IT solutions. Usually most of the work in this domain is based on the relations that was collected and modeled.

For each one of those domains I manage to prove to myself and others that using enterprise architecture we manage to do our work much more accurate and much more faster (thanks to reusing) . In the next posts I'll share how exactly I'm using EA to do each one of the described tasks.

Principles as enterprise architecture outcome

nattYGUR — Fri, 17 Apr 2009 06:26:00 GMT

Principles are the better half of blueprints. Principles enable enterprise architects to set up the boundaries that application / solution architects should follow to create their own architecture / solution, in order to build better enterprise architecture. Principles are actually set of rules which set the boundaries that needed to be respect and implement by all relevant roles in the enterprise. Together with blueprints principles enable enterprise architects to shape future architecture of a given enterprise.

Due to the fact that principles shape the enterprise we expect to see principles for each one of the four enterprise domains (Business, Information, Applications and Technology). In order to make principles more understandable and easy to follow we tend to write for each principle its name, a short statement, the rational behind it and any implications if the principles.

As with blueprints we (as enterprise architects) expect solution and system architects not just to follow the principles but also to embedded them in their solution in a way that we can use it while going through different reviews as part of the solution / system development life cycle. The most common why that I tend to use is to relate any architecture building block to the principles which was follow or implement.

To make it more easy to understand and practical you can find below a list of common principles taken from different work that I've done.

Name	Statement	Rationale	Implications	Type of Principle
All access to DB should be done using dedicated service layer	All access to DB should be done using dedicated service layer. no direct or custom data access.	Standard, reuse and management	Need to be checked as part of SDLC.	Application
All reporting should be done using BO solutions.	All reporting should be done using BO solutions. no room for custom solutions for reporting.	Reporting standard.	Validate this principle as part of SDLC	Application
All reports should be kept in original form for audit.	any statements sent to market participant should be kept as they were sent to the market participant	To be compliant with market rules.	Should be check as part of SDLC	Business
Application must pass Application Security Readiness Review	Any new application must successfully pass a Application Security Readiness Review	Maintain application security and to be compliance with Singapore government regulations	A SRR test should be done to each and every new application	Application
Application should be schema neutral	Application should be schema neutral. application should work against any schema defined in external setting file.	Be able to run applications in different environments == supports agility.	Applications need to be build in such a way that they can run against any schema.	Application
Be able to measure business processes	Any business prices should be measured	Measuring business processes enable to identify flaws and improve the process	each and every application that implement business process should measure time for each step in the process.	Business
Build loosely coupled solutions	Build solutions that enable application/components replacements without application rewiring.	Reach agility and flexibility of XXX to enter new business opportunities	Need to be checked for relevant design patterns in the SDLC.	Application
Changes to sensitive data should be audit	all changes to sensitive data (such as financial and HR data) should be Audit.	To be able to track changes made by humans to sensitive data.	Implementation of Audit in each application.	Data
DOCUMENTATION must be integral part of application	Documentation will be required that covers the following areas: * Technical specification * Operations * User instruction	Enable application maintain	Enable application maintain	Application
DB connection should be compatible for RAC implementation	DB connection should be compatible for RAC implementation	To enable solution supporting RAC implementation without code changing	Need to be checked for relevant design patterns in the SDLC	Application
Compliance to Oracle security standards and guidelines	general security control requirement applicable to Oracle database and server environment.	Increase IT platform stability	a. To prevent critical processes or resources from being unable to startup or encountered unexpected problem due to security hardening, the standards and guidelines described in this documentation should always be implemented in the development environment, fully tested, before propagating to the production environment.	Application
Data exchange across process boundaries and portlets will be based on entities	Data exchange across process boundaries and portlets will be based on entities. just entities, not custom data to be transfer across services, portlets.	Create one standard language to communicate between apps.	Should be checked as part of SDLC.	Application
Data should be accessible to each role that needs it	data access should me maximized to increase data sharing across the enterprise. the idea is to reduce compartmentalization to a minimum.	Increase data share across the enterprise.	Minimize data hiding.	Data
Design common code for reuse	Any code that is common or consider to be common will be develop and deploy in such a way that enable reuse	Maximize reuse.	Need to be validate as part of SDLC	Application
Design for IE 6.0+	The Market Rules do not specify inter-operability requirements that relate to Task 2. The implementation of these rules from a system perspective requires the use of 'industry standard IT practice' tailored to the needs	Support new markets and opportunities	Need to set standard and impose it as part of SDLC and as part of RFP.	Application
Design for disaster recovery	The solutions to disaster recovery are not usually the same as those for ensuring high availability. Whatever the criticality of a system and the replicating of all component parts to ensure maximum availability on component failure, the considerations of a complete site failure are not usually catered for. Disaster recovery has to cover a lot more than just the system components, eg personnel and location. The main consideration is the ability to provide the same functionality at a different site with alternative communications, with as close a replication of the system data as possible to the point in time of failure.	Enable market trading after system lost	Part of SDLC reviews (Architecture)	Technology
Design for performance	The performance requirements should be defined for each time critical sub-system	Improve trading product performance	Should be define for each system and checked as part of SDLC.	Application
EASE OF USE	The term 'ease of use' is a subjective measure. Ease of use can be achieved by user system features such as existence of documentation, consistency in human computer interaction, feedback for user actions, descriptive error messages.	Users satisfaction from working with our system	Set standard to Usability, Operability and Maintainability. enforce those standards as part of SDLC. Include those standards as part of RFP.	Application
Each Portlet that shows table should support export of data to external formats	such as PDF, Excel, CSV, XML	Ease user experience with the system. enable the user to use data for his own needs	Need to be checked as part of SDLC.	Application
Each component need to expose predefined services, but to implement needed function	Each component need to expose predefined services, but to implement needed function	standard way to consume services and reuse components.	Need to be checked as part of SDLC
Hot Deployment	Application must support hot deployment to prevent system outage while deployment.	Maximize availability	To be checked as part of SDLC	Technology
Information should be stored in databases	all the information should be stored in databases and not in any local machine or local storage (Excel).	To be able to share and use the data across the enterprise and to be able to effectively backup all the needed data.	No local storage of data. if there is a need for local storage, the data should be stored on DB as well.	Data
Java application must follow Java Coding Standards	Java application must follow Java Coding Standards	One standard coding across applications	Part of SDLC review need to check this principle	Application
New projects wont decrease current performance	New projects wont decrease current performance. new projects will improve or keep current performance.	Validate improvement of performance.	Part of SDLC should check if performance effected from new project.	Application
No logic in DB	All logic code that need to be written wont be done inside DB.	Separation between layers to enable agility.	Need to be checked as part of SDLC	Application
Solution must be able to fail over to another cluster	Solution must be able to fail over to another cluster	Maximize availability	Need to be checked as part of the SDLC.	Technology
System availability to 99.98%	Availability is a statement of the time for which a system or service is not operating as normal. The same availability may be the consequence of a number of short-term failures or a single long one. It is a combination of the failure rate (reliability) and the time required to restore the service (mean time to repair).	The need to support market available for trading.	Need to be checked as part of SDLC reviews (architecture and code)	Application
Use Automate test	Any new application should come with automatic tests and scripts that can be run at any time to check the system.	in order to improve our ability to embed new changes to existing application we need automatic way to check existing scenarios to identify new issues.	Any new application should come with automatic test tool and scripts that support scenarios.	Application
Use existing services wherever you can	Always use application platform services (Logging, Audit, authentication) instead of writing your own	Maximize reuse and make maintenance more easily.	Implement checking as part of SDLC	Application
Use existing technologies	Use existing technologies excluding .Net PL/SQL and Sonic MQ	Minimize portfolio.	To be checked as part of SDLC.	Technology
Use just existing entities	Just existing entities should be used	Entities creating one common language across the enterprise, applications and stakeholders.	any Interface should be implemented using entities. Any applications should implement existing entities.	Data
Using version control for all components	Each component should implement version control. the version control if for business process and business rules must have effective date.	for ease of management and track of changes.	Should be checked as part of SDLC.	Application
expanded by 20% from the initial data requirement.	expanded by 20% from the initial data requirement.	Support Expandability in minimum cost	Need to be checked as part of SDLC	Application

blueprint - an enterprise architecture outcome

nattYGUR — Fri, 10 Apr 2009 06:43:00 GMT

There are many outcomes to enterprise architecture work, but one of the important and most communicative one is a blueprint of your enterprise to-be architecture. People like to use city planning as an allegory to enterprise architecture. And similar to the role of city blueprints, which serves as a reference to building architects and designers, enterprise architecture blueprints are crucial for the success of enterprise architecture initiative.

In this post I would like to share with you a real-life example of enterprise architecture blueprint developed for one of my customers using system architect as a tool. The following blue print shows all the building blocks components (Information, Business, Applications and technology) and the relations between them as well as the defined interfaces between the building blocks and the interfaces qualities. We are using this blueprint for two main purposes:

It serves as a reference to application architects and designers to understand what they need to follow and what are their boundaries (we’re also using principles for this purpose, but I'll address them in dedicate post).
As part of the governance process we are using the blueprint in design review of applications to validate that they are compliance with the blueprint.

The blueprint is build from visual representation of all the building blocks and the relations between them. Following by textual explanation of all the building blocks, relations and interfaces that depicted visually.

The following blue print shows how internal applications need to be developed in order to support enterprise mash-up of different information types both for internal and external customers. It contain the main building block that each application expected to build and the allowed relationships between those building blocks. For example note that each application should separate it business rules, business tasks and business events and business conditions (to better support business agility). The application information is separated from actual data as business objects that are defined by the business and serve as the only data types that can flow between applications. The common layer is a set of common infrastructures that can be used by any application.

Following the visual representation of the blue print we provide a details explanation of all of the building blocks an the relations between them. It usually looks like that:

		Blueprint description
		Portal: · Enable to show and work with portlets that represent different data on the same page. · The portlet enable those potrlet to communicate one with each other in order to change display in one portlet as a result of data changes in other portlet. · The portal also enabled the user to choose which portlets are going to be displayed and in which order.
		ESB : · Enterprise Service Bus responsible for providing and consuming loosely couples web services. · The ESB should receive calls for services and to rout the request to the right physical address where the request service can be executed.
		Common Layer: · This layer contained all services that are common for all application. · Components in this layer should be write in a way that they will support each and every application (no custom code) · Components in this layer should be load into the memory space of each and every application and access directly by the loaded application components.
		Identity Management · Single point that handle user access to systems. · No identity management code should be exist inside application implementation code.
		Logger · Single point in systems that handle all types of logging · No logging management code should be exist inside application implementation code. · Selected tool for this building block is Log4j.
		ORM · Single point in systems that handle all access to DB. · ORM should provide mapping between relational DB and OO Entities, including the needed code to perform CRUD actions against entities. · ORM should provide access to data in-memory as first choice · No direct access to DB should be exist inside application implementation code. · Selected tool for this building block is Hibernet .
		Communication Manager · Single point in systems that handle all access to Access FTP, Queue, Files, Email. · Communication Manager will provide single point to getting or sending any type of the FTP, Queue, Files, Email. · Communication Manager will implement all handlers and listeners that exist today in single point. · No direct access to FTP, Queue, Files, Email should be exist inside application implementation code.
		Application (Solution) : · Application represents set of components that run in the same memory space, have the same version and maintain by one group. · Accessing component inside application is doing using services but not web services. · Accessing components services from outside of the application is done using web services. · Each component has one or more interfaces that must be exposed but not implemented. · Just needed functions in an interface will be implemented.
		Presentation layer: · Presentation layer responsible for formatting data into user display forms and portlets as well as manage forms flow, where it applicable. · This layer is build from portlets, which are used to display application data on a portlet. JSP pages, which support the user to go through several forms to perform his work. Needed interfaces for each architecture building block
		Portlet: · Responsible to show application data on a portal.
		JSP: · Responsible to provide user interface as well as user interface flow for a worker.
		Report Manager · Responsible for retrieve and format data from other DWS or operational database. · Should be the only responsible for formatting data for reporting. · Could access data access manager or directly DB for getting data
		Business Rules Management · Responsible to perform formulas calculations. · This component is responsible to encapsulate calculations of business rules. · The only place where business rules calculations will take place is just in this component. · Business Rule Management should access Data Access Manager layer in order to pull there data it need to perform it work.
		Business Process Management · This component responsible for running business processes. BPM is composed from Tasks, events and conditions which form the business process. · Business process might call a business process rule, Information workflow, ReportManager or In/Out bound interfaces to perform it duties. Business process is just responsible for running a process. business · Rules calculation, data access and validation, accessing external services or generation/requesting reports must not be part of the business process code.
		Task · Task is responsible to perform certain task in a business process. · One of the most important duties of a task is to compute and store the time that it takes hi to perform his work.
		Event · Responsible to handle business process event
		Condition · Responsible to perform a business process condition.
		Data Access Manager · This layer responsible for accessing and validating data. · Data Access Manager provide intermediate layer between OO work and relational database as well as a layer that minimize DB access (by providing in-memory storage)
		Information Workflow · Information Workflow responsible to perform cross business objects call to collect data or to perform any task. · Calls from other application objects are reaching always information process object that responsible to perform calls to one or more business objects. · No direct calls will be made from other components than information workflow to business objects.
		Business object · Business objects are dedicating entities that combine data from the ORM together with the relevant business logic (mainly validations) that can be done in the entity level. · BO are being called by information flows and using ORM entities to get the data.
		ORM (Entities): · ORM - is the layer that responsible for translating relational databases into OO structure. · Each entity that takes part in application should be representing in the ORM level. · Each Entity should be encapsulated with CRUD function by the ORM.
		Web Services · Web Services is a layer that responsible to separate code that is needed to provide internal service as a web service or to consume external service. · Web Service layer is build from inbound and outbound elements. Inbound is responsible for wrapping internal service as standard web service as well is to impose restrictions for web service usage (such as limitation of concurrent calls) · Outbound is responsible to wrap calls to external web services. web service layer responsible to decoupling of web service calls from internal implementation of any of the application internal elements.
		Inbound · responsible to encapsulate internal services as web services and to receive incoming calls for web services
		Outbound · Responsible to encapsulate calls to external web services.

Last but not least is the services that we expect to be implemented by building blocks and interfaces implementers. Those services could be looked like the following example:

Following by textual descroption:

		Building blocks interfaces
		Portlet
		*IPortletComm*: · Show(Entity) - get data and display it called by portal to initiate portlet on the first time · Refresh(Entity[]) - Refresh data on screen by other portlets / portal · GetAvailableEntities(Entity[]) - what are the entities that i can support as para,eters for call my refresh function.
		*IPortletBehavior* · Minimize · Maximize · Move · Hide · Close
		Outbound
		*IOutBoundPA* ExecuteExtService(NameOfService, Params) Results
		Task
		*IBusinessTask* · GetTaskStartTime · GetTaskEndTime
		Business Rules Management
		*IBusinessRule* · ExecuteRule(Name, Params) Results
		Report Manager
		*IReport* · convertFormat(Full_filename, DestFormat) - convert the report data into requested format (Excel, CSV, XML, Entity) and store in file specified by filename · generateReport(ReportName) - generate pre-defined report based on reportName, return status and store internally as a DOM object · GetReportList(GroupParam) - Return reports list · ScheduleReport (TimeParam, ReportName) - schedule the report by given params · GetSavedReport (ReportName, Date) - as part of producing reports each and every report should be saved to CSV and signed PDF. this service should return those two files by report name and dates.
		Information Workflow *IInformationProcessor* · ExecuteAction(ActionName, Params) - execute one of the information workflow that ewsponsible for · calling several (or one ) business objects in order to do some action or return data back to the calling processStep or Rule engine.
		Business object
		*IBusinessObj* · Query(Entity, criteria ) - to return the list of ID based on the criteria · Retrieve(Entity_ID) - to return entity based on the ID · RetrieveByParam(Entity_ID, AttList) - Return list of attributes of given entity by AttList · Create(Values[]) - Forward to ORM · Create(Name) - Forward to ORM · Update(AttList, Values[]) - Forward to ORM · Delete () - Forward to ORM
		Identity Management
		*IIdentifyMgr* · requireSecondLevel(Process_ID) - check if the process requires 2 factor authenication · isAuthenticatedFirstLevel (UserCredential ) - if the user pass level one security · isAuthenicatedSecondLevel(UserCredential) - if the user pass level second security (RSA, certificate etc) · isPermissible(Process_ID, UserCredential) - check if user has right role to execute the process · getRoles(UserCredential) - get the list of permissible roles user has · getUserCredential(User_ID) - get the User Credential entity based on user id
		Communication Manager
		*ICommunicator* · performFTP(Filepathsource, filepathdestination, filename) · performSecureFTP(Filepathsource, filepathdestination, filename) - perform secure FTP to transport a file from source to destination · performSMS(Phone_number, text) - SMS text to the phone number · performEmail(email_address[] , template_id, file[]) - email out to all addresses with the template and attachment file · perofrmSecureEmail(email_address[] , template_id, file[]) - same as above except secureEmail · ListentoFile(filename, filepath) - listen for the incoming of file at the path and creates an event · ListentoSMS(phone_number[], text) - wait for a sms from the phone_number list) and creates an event · ListentoEmail(email_addressp[) - wait for emails from the list email address and creates an event

This blue print, as I already mentioned above, is also served as a guideline for applications architects and designers and as a tool in our enterprise architecture governance process. We accept application architects to connect each building block in their solution to one of the building blocks in the blueprint as well as doing the same for architecture principles. This enable us to find quickly who much the proposed solution is compliance with our architecture.

I can know if your complex IT project will succeed!

nattYGUR — Thu, 02 Apr 2009 05:03:00 GMT

Draw two identical lines (same length). One (the upper) represents the time invested in applications life cycle and the second (bottom) line the human resources available for your IT organization. On the first line draw a point which represent how much time your organization invest in systems development. Take in account that from the drawing point onward it's a segment that represents the time needed to maintain systems. Usually the dot will separate the line to quarter and three quarters.

Now, draw a dot on the second (bottom) line which will represent the relative amount of human resources that your IT invested in application's development. Keep in mind that the segment from the point onward represents the relative resources invested in maintaining applications. Usually the first segment is three quarters, which support development and the second segment is one quarter, which supports application maintenance.

Having the dots, which splitting the lines, connect the two dots with a line. There are three types of lines that you should get "Vertical" (90 angle) line from the upper line to the bottom line, a diagonal line starting from right to left, and diagonal line starting from left to right. Each one of those lines says a lot about your IT.

Let’s start from the most uncommon scenario; the diagonal line goes from right to left. This implied that relatively more human resources go to maintaining systems rather than for developing them. This line is common for enterprises that are based on cloud computing services. If you’re buying software services rather than developing them, than most of your human resources will be focused on maintaining those applications. This scenario might be the "Best Scenario" that many CIOs are after.

"Vertical line" is also not so common. It imply that your human resources are rational to the time spend on developing or maintaining systems. Sorry to say it but I never saw a company with this type of line. This might be the ideal situation, but in reality it simply doesn't exist.

The most common scenario is a line starting from left to right, which implies that most of the human resources goes on developing systems and less resources on maintaining the system (although maintain the system is a task that last much more time). This scenario can be seen in most of the enterprises, the only difference is the angle of the diagonal. The more the angle sharper, the more IT portfolio is less management. In enterprises that fully maintain IT portfolio we expect to see a list of: Supported business capabilities, Managed Information, applications, Databases, Servers, storage, certain amount of attributes for each collected data (such as Cost, usage, Availability, etc') and relations between them. But, as the angle is sharper less of the IT portfolio management outcomes are available. It can start from missing attributes and relations, through missing some of the assets (such as capabilities and information) and end up with irrelevant list of assets or even unexacting list of assets.

As far as I managed to see (and It’s just what I’ve heard and seen) there is also direct relation between the diagonal angle and the ability of the enterprise to run a complex project in time. Organizations with sharp angle simply tend to fail in complex projects, while organizations with less sharper angle tend to finish complex project on time.

How to build practical enterprise architecture team

nattYGUR — Thu, 26 Mar 2009 16:33:00 GMT

Enterprise architecture team might be the successful CIO right hand (especially in today economic situation) or a group of people that you can’t really understand what they are doing. A successful enterprise architecture group will help you to reduce IT costs, optimize IT operation, make better IT planning and keep the enterprise compliance with laws and regulations. The problem is that in order to build a successful enterprise architecture group, there is huge learning curve that CIOs need to go through. If you wish to reduce your learning curve significantly, keep reading.

There are 5 main Steps that you have to understand and follow. Because each step influences the others, I tried to order them by dependencies:

1) Have a clear understanding what EA means for your enterprise.

The term ‘Enterprise architecture’ has many definitions running on a scale that moves from a purely business oriented definition to a technological one. The first thing that you should do is to define your enterprise architecture. Is it applications integration architecture from an enterprise point of view? Is it business process re-engineering that will increase business operation? Is it an attempt to align IT to business? Or is it a process of understanding all of the enterprise domain building blocks (Business, Information, Application, Technologies) and their relations to be able to better run IT?

Every definition is legitimate and right, but each one of them will take the enterprise architecture in a different path. Without a clear definition of your enterprise architecture you will spend a lot of time to find the definition on the move, causing changes in each one of the following steps and increasing significantly your learning curve.

2) Define what are the results you expect your EA team to deliver

Having the definition is not enough. Next step is to define the results that you want your EA team to produce for you. Those results should be explicit and followed by the deliverables expected from the team.

As I’ve argued above, the results and deliverables are the outcome of your enterprise architecture definitions. Results and deliverables of business oriented definitions will look different from technology oriented definition of enterprise architecture.

Results and deliverables should be explicit. If your EA definition is “a process of understanding all of the enterprise domain building blocks and their relations to be able to better run IT”, the result should be:

· IT long term planning showing better alignment to business, BCP planning, Merge and Acquisition planning.

· Decrease IT costs.

· Increase IT availability

· Increase compliance with laws and regulations.

The deliverables should be a list of reports, excel sheets, visual views (Diagrams), dashboards or any specific outcomes you expect to see from your EA team

3) Build the right team with the right people

Having EA definition, results and deliverables is the base to start looking for the right personas for your team. Should you look for technology guys, with specific knowledge in certain technologies or vast knowledge of different technologies and trends? Should they be people with business (industry) knowledge? Should they come from IT or from business teams? Should they have modeling knowledge? In any specific standard (BPMN, EPC, IDEFX, ERD, etc’)? Should they be more soft skill oriented people, with the ability to reach common agreement or a combination of other soft skill characteristics?

Building a team before having enterprise architecture definition and clear understanding of results and deliverables ends up with a group of people who might be incompetent with regards to the task you want them to carry out. Needless to say, after creating an EA group it won’t be easy to change the group members.

Due to the fact that most CIOs simply don’t have time to deal with the first two steps, a common approach is to hire one of the team members or a consultant to go through the first two steps.

4) Invest time to build the team unique value

This is the most crucial step and the one that most enterprise architecture teams are lacking. It’s not enough to take a group of talented people, call them enterprise architects and close the deal. Let’s face it- you (and others) listen and accept what the DBA, system analyst, software architect, program manager, etc’ has to say in a discussion because they have proven expertise in certain domains. The same principle has to be implemented for enterprise architects. The problem is that if you take a group of people with an existing knowledge of the enterprise, they won’t have any unique knowledge to offer! In order to help them to have this unique value, some investment will need to be made.

Again, the content depends on the context that we discussed in steps one and two. If your enterprise architecture definition is based on the ability of the enterprise architect to bring a holistic view of the enterprise by introducing a knowledge of all the enterprise domains (business, information, application and technology), then investing the time for collecting and modeling all the needed data on those domains and their relations will make the difference. (The same collecting and modeling of data can be applied if you just focus on the enterprise technologies or applications).

This exercise helps enterprise architects to acquire information and knowledge that are unique to them, especially when any other roles are just focused on their own domain.

Having unique knowledge that is needed and appreciated by CIO and other roles in the enterprise will make or break your enterprise architecture team.

5) Demonstrate your EA team value in a short term project

When you have gone through all of the previous steps it’s time to show what value enterprise architecture can bring to your enterprise. Give the enterprise architecture team an assignment with a clear success / fail indication that will be done within two to three months and will demonstrate that your enterprise architecture team unique knowledge can contribute to the enterprise in a way other roles couldn’t.

One of the hottest topics now is cost reduction, so pick an area where you feel that your unique enterprise architects knowledge will help them to gain success in a place where others didn’t and ask them for a result within two to three months.

This short term project is important to the enterprise architecture team from two perspectives- it helps them to gain self confidence and understand what they are doing and how it helps the enterprise; it also helps other roles in the enterprise to understand and value enterprise architecture contribution to the enterprise.

Summary

One of the most common problems that enterprise architects are facing is vagueness regarding what they need to do and how the CIO expects them to do it. Sometimes as an enterprise architect you can feel like a child that was asked by his father to bring some candy from the grocery store and every time that he’s coming back home with new sweets his father’s sending him back to the store because he doesn’t like what the child just brought him. Having your enterprise architects in a similar position is harmful! Be as clear as you can when explaining what you want and what are the outcomes that you expect to see.

IT('s) Simple!

nattYGUR — Thu, 19 Mar 2009 20:36:00 GMT

When I suggest the idea of mapping the enterprise IT assets, I usually got the answer that it's a waste of time because “IT is simple“

This diagram represents an average customer that I'm dealing with. This is an example of an American company with 300 applications, 150 products (COTS), 100 databases, around 50 technologies and more the 1,000 servers. The diagram shows the instances of the mentioned above building blocks and the relations between them:

Do you still think that IT is simple?