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.

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

P.O.W.E.R.

Lately I've been building a lot of models. As many may know, my role at my company is a mix of Enterprise Architecture and Technology Strategist, with project work to keep me busy. I spend the majority of my days working out how improving various technology systems relate to real business goals. I like to think my work provides information that supports good business decisions.

Sure, there are many different frameworks one can apply, such as TOGAF or Zachmann. But in the real world, few organizations adopt the entire framework. They take a smattering of TOGAF and a little of ITIL, then build out projects based on Waterfall or Agile project management methodologies. Finally, they bundle all that up & call it their "process". In my many roles in this industry I have seen how well this works - or doesn't !

 

A friend of mine has challenged me to write about how I have been successful using an adapted model, and how to re-apply that model to other Enterprises. I sought his counsel on how to go about doing that and he introduced me to a very simple (hence very elegant) writing method: P.O.W.E.R.

P - Plan: what are you writing about ? Who would the target audience be ? What style of book should it be ?

O - Outline: build out an imaginary table of contents. What should be included ? In what order ?

W - Write: simply go about the business of collecting your ideas on your word-processing application.

E - Edit: word-smith. Play with sentence structure. Play with the order of your ideas. Hack & slash as needed.

R - Release: it'll never be "perfect", so when it is good enough, stop. Publish. Think about the next book !

It's a simple yet powerful (you see what I did there ?) way to begin the process.I think I'm going to take a stab at it, and see what happens. But don't expect to see my name on the NYT Best-Seller list - it'll be a technical/architectural manual, so it might only appeal to a limited audience.

 

Posted with Blogsy