LINKProcess™

LINK Process™, a methodology for business analysis and requirements analysis, guides how we do projects. Developed by Doreen Evans Associates from best practices developed over 12 years of experience, the LINK Process methodology has been used successfully on projects at insurance companies, government agencies, telecommunications companies, and financial services companies.

Why We Developed the LINKProcess Methodology

There are many methodologies available today – the STEP methodology for business rules, RUP, and so forth. Most focus on building systems. While this makes sense at first glance – after all, isn't building a technology solution what we're aiming for? – we believe that the business process is missing.

Without a thorough understanding of the business process, you are in danger of building an excellent system that doesn't meet a real business need. We've seen this happen more than once. Sometimes, after a business process analysis effort we've even seen organizations make a decision to change the process and, with that change, determine that they don't need the system they thought they did.

The LINK Process approach ALWAYS starts with an understanding of the business process. From there, we develop requirements for three potential areas:

• Changes in roles
• Changes in process
• Changes in technology

In short, the LINK Process methodology focuses on business process analysis and then on requirements for whatever purpose is identified as being most crucial. The requirements deliverables we produce are created in a repository and, as such, can become the basis for subsequent work including systems development, creation of a rules engine, workflow implementation, and business process management efforts.

What Does the LINKProcess Methodology Consist of?

There are four basic principles of the approach:

(L) Lead with Business Understanding. This means that you NEVER launch a systems development effort without first understanding the business process that the system will be supporting. You do this primarily so that you can ensure that the system you develop meets real business needs. Your first goal is to prevent the wrong requirements from being developed. But it’s possible that you may discover that what really needs to be changed is the process itself, or that a simple technology change such as a scanning capability may bring significant improvement. In addition, understanding the business process provides a context for discovering business policy and becomes the beginning of documenting business rules that may be appropriate for a rules engine. The business process also guides what are known as “process rules”, that is, those rules that outline when things should occur and in what order. Thus the business process can also become the basis of a business process management effort.

(I) Identify Critical Requirements. This means that you follow a systematic approach to identifying the requirements that the business deems important. These requirements might be for role changes or for process changes. For example, if an insurance organization wants claims processed more efficiently and with better decisions along the way, they may decide that they need to institute a ‘triage' team at critical points along the claim review path. In this case, your requirements would focus on defining the new ‘triage' roles and on where in the process the team will participate. More often you will be defining requirements for a system. With the LINKProcess approach, you are in a position to ensure, first of all, that the requirements you are gathering are for a system that will actually meet business needs and, secondly, that the requirements are based on what the business wants. In the LINKProcess methodology, we recommend that requirements be gathered by what we call a requirements architect – a person who can communicate with both business and IT, much the way that an architect communicates with the building's owner and the builders, electricians, plumbers, and masons involved in a construction project.

(N) Navigate the Deliverables. This means that the business analysis and requirements deliverables you create are used in many ways through the life of a project. For example, the use cases and data models created during requirements analysis can be transferred to an object-oriented tool such as Rose to jump-start the design effort. The business policy and business rules identified are captured in such a way that they can be separated from other deliverables and used in development of a rules engine. The process flows can be exported to the business process management language (BPML) and used for business process management efforts, or they can help drive workflow rules. System requirements can generate user acceptance test scripts. Finally, artifacts from project work become candidates to help the organization build an enterprise architectecture.

(K) Keep a Knowledge-Asset Repository. This means that you want to store all the deliverables you create during business process analysis and requirements analysis. Why? Many reasons. Storing the deliverables in a repository means that they are available for communicating to all project participants, especially if the repository is available on the web, and for jump-starting subsequent work. The next time a system enhancement is contemplated, you already have the requirements that represent the current system to start your work.

What Makes the LINKProcess Approach Unique?

LINKProcess provides:

• The structure and standards for descriptive representations of the enterprise or of a project
• A framework for collecting, categorizing, and utilizing architecture and engineering information
• A standard architectural approach to ensure that projects and solutions can communicate and interoperate
• A formal metamodel of architecture products, structures and their interrelationships across many views of the architecture
• The use of enterprise architecture modeling tools tightly integrated with the methodology to support the organization, documentation, and iterative nature of the process
• Documentation generation utilities to automatically generate deliverables from the repository
• A web-enabled repository that integrates all project work to publish, collaborate and manage the review and change process for project assets throughout the life cycle.