Framework Flexibility - From CLAP to CLIP

As many readers may have noticed, there are some fairly significant gaps in the CLAP Framework. In the perfect world, it is really intended as a guide for how to execute Business Goals into practical IT Projects. But there  may be some flexibility in the simplicity of that framework.

A colleague pointed out that maybe the missing component wasn't necessarily the Application, as those needs are covered off in the Functional Requirements. He suggested that instead the framework should consider the Information Architecture itself.

For the purposes of this framework, lets consider that data is the raw input of a process, and information is the output. Information needs to have a defined structure and each element has a distinct meaning. Consider the difference between distance an speed. Distance is a unit of measure, denoting how far something is. Speed is the distance divided by the time taken to travel the distance. Speed is the result of a process. applied to the data.

In the CLIP Framework, the notion of Information Architecture is added. It describes the processed data, its flow from system to system, and its attributes. For example, is information synchronous (live from a source) or asynchronous (delivered by a different process). Further, we see where the Requirements and Standards get applied, and how Security Requirements need to be considered through every step of the process.

Finally, we see the Validation step happens just before the solution is transitioned to Operations. It asks the question "Did the final physical solution deliver what was designed ?". Arguably, there is another validation step, which asks the question "Does the Solution Architecture satisfy all of the requirements ?".

The validation is key, as this largely waterfall process needs to map the entire solution all the way back to the original Business Activities, described in the functional & non-functional requirements. As you can see, the framework is flexible enough to be applied to many IT Goals, and not so rigid as to be unmanageable.

Pulling It All Together - CLAP + PMLC

In a series of previous posts, we took a look at various frameworks for bringing valuable IT Services to an Enterprise. Starting with the CLAP Framework, we saw took a look at a basic way of starting with Business Activities and building the necessary Conceptual, Logical & Physical Infrastructures to deliver valuable IT Services.

Next, we saw how to use a tool like the ERRC Canvas to achieve the Enterprise Strategy, by mapping the strategy to goals & objectives. The key function of the canvas is to separate the objectives into four areas: Eliminate, Reduce, Raise & Create. 

Once divided, metric for success are applied, and plans can be created. These plans can be prioritized and dependencies mapped. Getting from Business Strategy to IT Execution is no easy feat - so this post describes a method of execution.

Of course, understanding goals as they relate to Strategy is also very important. We took a look at how to create SMART Goals.

Illustration: CLAP and PMLC Together on One Page

We are now in a position to pull all of those concepts into one diagram, shown above. I have attempted to layer the various concepts together, and embellished them with some extra information, such as when a project can expect to need to engage various roles within the RACI.

Finally, we see three vertical lines which describe a form of IT Governance. In a future post, I will describe the make-up of the ARB/TRB and explain the importance of the Architectural Validation Plan.

Business Service Model for IT

IT exists for one purpose: to provide the tools necessary to enable Business Activities. Like we saw in the CLAP Framework, Business Capabilities are made up of a number of discrete Business Activities. But it is in the delivery of the Business Capabilties as a Service that IT provides value to the Enterprise.

The model for a Business Service is clearly defined by the ITIL framework. In short, it is composed of People, Process and Technology. Certainly, the framework also describes the meta-data, which includes the Service Owner, the Service Consumer and the Service Provider.

Once the functional and non-functional requirements of the Business Capabilities are mapped out, the application and its underlying infrastructure become straightforward to build out. As I have posted about previously, the Project Management Life Cycle can be easily applied to deliver these capabilities to the Enterprise. Of course, more than one capability can be provided by a single service. Often many services get grouped together to form a broader service.

There is also another relationship hidden in a simple model like this one. The degree to which a process is repeatable (and can therefore be automated) has implications to the People part of the equation. The more highly repeatable and automated a process is, the lower the required skill-set for the labour, which should in turn lower the cost of the Service to the Enterprise.

Posted with Blogsy

From Business Strategy to IT Execution

Illustration - Strategy to Execution

As we have seen in my previous posts, I am always keen to tie IT Activities to Business Strategy. Whether it is in utilizing the CLAP Framework to map Business Activities to physical IT infrastructure, or in achieving your goals using the ERRC Canvas, the end-goal is always to drive Business Value.

In this basic diagram, the basic questions of Who, What, Why and How are directly addressed, leaving the When up to the Executive sponsors to decide in the Project Charter. The centrepiece is the ERRC Canvas, which helps define the Objectives (the What) & IT Activities that would meet the Goal. As with all SMART Goals, the element of Metrics help define the How.

Finally, the Plan is actually the domain of the Project Management Office. It would include the Project Charter and supporting artifacts, including dependency maps and budget estimates. Conventional Wisdom is that the Project Manager is responsible for Time, Resources and Budget.

Posted with Blogsy

CLAP Framework for IT

Many Enterprises struggle with IT frameworks. These frameworks are meant to help turn Business strategy into executable plans. Some frameworks, such as TOGAF or Zachmann will help an Enterprise IT group understand WHAT it needs to do to achieve its goals. Other frameworks, like COBIT or ITIL will further explain HOW to achieve those goals. When an Enterprise does not follow any of the established frameworks, they will often try to devise their own. The diagram above illustrates one such framework - the "CLP" framework (the "A" was added later, after missing information was identified).

Conceptual - this stage of the framework takes the Business Activities into account. Each discrete activity can be mapped out as a few elements in a process, describing a single activity. An example might be "calculate price".

Logical - this stage maps the discrete activities required. To calculate price, we need some information from a number of sources, such as the gross price, a taxation rate, a discount and a profit margin. Further, architectural governance (standards) are applied, such as use of a Linux operating system, or mandating a particular security framework. Finally, Non-Functional Requirements (NFRs) are described, such as how quickly a system must respond or how many transactions per minute the system must satisfy.

Application - this stage is where we begin to apply some business logic about what to do with the information. It maps out what the information should be expected to look like, such as expressing numbers in Currency notation, with two decimal points of precision. It will also describe any user interfaces and other means of accessing information. It specifically maps business activities to Functional Requirements.

Physical - this final stage helps identify all of systems that are required. Items such as CPU utilization and storage requirements are calculated to determine how best to implement the system into a computing environment. It describes systems interactions in terms of protocols and transports.

This is not an exhaustive look at frameworks, and many Enterprise Architects will keenly assess missing elements from this simplistic framework. But, executed properly, a framework such as this one could be sufficient for an Enterprise to begin taking advantage of IT to realize their business strategy.

Posted with Blogsy