OracleAppsBlog
A day in the life of an Oracle Applications Consultant

Sunday, June 13, 2004

Legacy Management Part B

All projects start with some level of legacy management, be it software development or ERP implementation, it involves legacy systems and their future role as business process base. The business process that is more or less embedded in legacy is of importance viz a viz proposed automation too. To begin with our projects we must develop a sustainable approach to legacy management.

An article from the Gartner Group:” Building an IT Strategy When There is no Clear Business Strategy” (Gartner - John Mahoney) states following rules of the game:

a. Best Practices


1) Connect all IT proposals to business goals and metrics or to the necessary base infrastructure, if necessary, by establishing new measures. Use these connections to prioritize and measure IT proposals in business terms. Keep the model simple and flexible.
2) Communicate frequently and clearly to ensure that all-important issues are considered and to avoid misunderstandings.
3) Limit strategy creation to a predetermined period, and review and update the strategy later if necessary as circumstances change. It is better to have an initial direction and a sketch map so that the journey can start rather than wait until the whole journey is mapped in detail.
4) Ensure IT planners are represented in business-strategy planning teams from the start and throughout the process.
5) Engage top leaders in the enterprise to resolve strategic ambiguities and to manage uncertainties and risks.


b. Common Errors


1) Attempting to create inappropriate detail and false certainty.
2) Building or expressing IT strategy in terms of technology drivers rather than business objectives and benefits.
3) Failing to connect IT strategy to a business value model.
4) Creating the impression for enterprise business leaders that the IT organization is trying to take over business planning.
5) Spending excessive and uncontrolled time on consultation and consensus building.”
6) Worst of all, subjecting professional and technical decisions making to non technical staff

Bottom line—Back to Basics! Business Planning and Analysis are key messages that need to be embraced by all levels of management, and involvement is mandatory. Successful implementation of any chosen technology will only be successful if the people using the technologies are committed and trained, and management has provided a clear message on the use of the technologies. There is no magic, just plain old common sense and experience. Effective plan must be:

1. Must be rapid process.
2. Provide brief and clear output
3. Integrate context to greater and detailed strategic plans.


A. First Step: Gain Understanding of Organizational Operations.


Our first step should be one of gaining understanding. We need understanding of all of our current assets wherever they may be, human and technical or otherwise.

1. Understanding our human capital means we need to understand where the expertise and skills are and how they relate to our inventory of software and hardware.
2. Who in our organization has the business expertise relating to: vital legacy applications, installed packages, new services, and Web applications?
3. Who in our organization has the technical expertise for these assets?

Understanding our technical software assets means:

1. Making and verifying an inventory of all existing applications
2. Including the technology requirements and skill sets required for each.
3. The business functions that each application supports.

Having this matrix of resources, applications, skill sets and human capital, we will be able to see where the most important business functions are supported and how. We need to catalogue what we have, where it is, what it does, what technology is in use, what database management systems, what data does it contain, what data does it own, how does it interact with other assets, what is the timing of events. This would generate an X-Ray of our IT activities and assets, giving us a deeper look into the overlaps and missing pieces and huts help us understand how to go forward.


B. Second Step: Planning of Proposed Operations.


Planning change is different from standard project plans in the sense that it necessitates inside-out approach. This will be a new kind of planning, tactical and strategic for an ever-evolving portfolio. Not a static or linear model, but a perpetual, adaptive and evolving model. Legacy management is not a one time issue or resolution, but developing a strategy of interoperability and interpolarity. A service oriented strategy to match the new model with our service oriented component architectures that we should adopt. Our project management techniques will need to plan for collaboration from many different knowledge domains—business and technical. We will need to develop and adapt to a multi-path multi-disciplinary integration methodology.

Skills management and detailed training plans will be very important, as our assets will lie in many different technologies. Strong architectural skills will be of the essence. New tools may be required to support the detailed cataloging of the business models and the technical components that support them.


C. Third Step: Produce Architecture for Organizational Operations.


Perhaps the most important step will be the production of the architecture that supports our new outlook, along with the plans on how to map our current assets to it. Using new integration methodology and business modeling tools we need to develop our new business model based on this new thinking regardless of what currently exists. This leads us to go for a through upgrade of applications, rather than to adopt isolated instance of what is new; an Enterprise wide scope.

Every asset we currently own is a possible component of our architecture. Whether it is new or legacy or a purchased application component does not matter. What matters is, it has a usable component that satisfies the business need. Our understanding of these current assets will be vital as we go forward. Our previously developed inventory can be used and we will need to dig into each application to find the real services that can be reused.

Once we have this new architecture and can see how our current assets map to it then we need to implement. We will use a variety of techniques and tools to isolate and wrapper functionality from legacy applications preferably using non-invasive techniques. We will most likely employ AIM and middleware tools, which already have process workflow designers built into them. We will make use of wrappers and connectors to purchased solutions. And we will continue to develop new services with our choice of component and service oriented development tools. All this should be technically and professionally wrapped in any good RFP.
Our ultimate target is an ERP with loosely coupled, workflow based, service oriented portfolio of software assets, which is flexible enough to manage rapid change over time and support new business practices as rapidly as they occur and is achievable.


D. Legacy Component Services and Future.


Yet it does not mean that the thousands of dollars invested in legacy applications must be wasted. Duplications stand to go. Those legacy assets can still be utilized to deliver new services meeting our time to market goals and possibly at a lower cost than totally new development. .


E. Back to the Basics.


Organizations today are looking to new technologies to improve their organization’s competitiveness. That’s why IT must not only support, but also shape every company’s ability to manage customer relationships and business partnerships, and to introduce innovative products, services and distribution channels. And move away from the 80’s—“isolated islands of technology”. With proper business analysis, organizations can progress cautiously, minimizing risk, and providing users with functionality they not only want, but also need! Through the business analysis process, IT infrastructure is enhanced with a clear set of “technology stakes” presented to the users, and constant review and updates to business processes manages changes in the business.

At the core of these changes is the internet computing model; a gradual shift from client/server. These objects provide IT with the ability to quickly and accurately model business requirements for end users and provide the basic building blocks for new functionality. These basic functions are available today in many new tested technology environments from J2EE tools, ‘Self Service Modules’ and its rival, .Net. So the question is not what tools can I use, but what do I want to accomplish with these new tools? “Back to the Basics!”