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

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

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

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

Introduction

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

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:

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