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

Mapping Projects Back to Strategies

In order to be successful, IT needs to closely align its services to the Business's Strategy. This requires that the Enterprise Architecture group have a clear idea what the business strategies are! While I am actively studying the TOGAF architectural framework, I recognize that many Enterprise customers are unwilling to completely "buy in" to a specific framework. So this series of BLOG entries look to fill the void.

Illustration: Mind Map of Strategy to Goals to Projects

In a previous post, we described how the ERRC Canvas can help support the Strategy, by helping achieve the Goals. As we move from left to right through the above illustration, multiple Goals might be required to realize a Strategy. The ERRC canvas is a great tool for identifying activities, which broadly fall into the categories of Eliminate, Reduce, Raise and Create.

Building on that theme, and assuming we want SMART Goals (Specific, Measurable, Attainable, Relevant, and Time-based), we can identify the Metrics, which are the measurements of success. Assuming we can cleanly map between the ERRC Canvas (representing the Goals) and the SMART Metrics for those avtivities, we can derive a Plan or Project to implement those Goals.

On the far right, we see the conventional wisdom that Project Plans contain elements of Budget, Timeline & Resources. The Project Plan is a culmination of the Strategy (Why), the Goals (What), the Metrics (How Much) and the Plan (Who). The Project Charter can define the When, as well as any required sequencing.

If you're curious about how projects evolve from a Project Charter through to successful delivery of the objectives & goals, take a look at my previous entry, entitled Project Management Life Cycle. I cannot stress enough the importance of proper planning ! When in doubt, think of the axiom "measure twice, cut once".

Posted with Blogsy

Project Management Life Cycle

Illustration: Project Management Life Cycle

We all know that IT projects don't just happen. They usually start with an idea that gets socialized internally, until somebody decides it is interesting enough to write a business case, justifying why the idea might be good for the Enterprise. The Project Management Life Cycle (PMLC) walks the reader, from left to right, through all the components of a project. It assumes the project has been instantiated and has executive sponsorship. Other activities prior to the project itself include the Opportunity Assessment, a Cost/Benefit Analysis, and likely ROI and TCO studies.

The PMLC illustration above is designed to show three things at each stage: the roles that contribute to the project, their responsibility and their deliverable. Starting on the left, the Stakeholders typically sit on a Steering committee, and provide budgetary approvals for the project.

The project is run by the Project Manager, who is responsible for budget, timeline & resources. They usually draft the Project Charter, which defines the objectives and scope of the project. They are responsible for reporting back to, and taking direction from the steering committee. It is their responsibility to deliver the project to successful completion.

The Business Analyst does a lot of leg-work, dealing with the stakeholders to understand requirements, both functional and non-functional. They will take raw data they have collected, and produce information which is valuable to the project, and consumable by all members of the project team.

Now that you have a general idea of the flow, you can interpret the rest of the illustration for yourself. Other information that will later become key is called the RACI. It is an artifact that names all of the roles (as seen in the illustration), and determines who is Responsible, who is Accountable, who is Consulted and who is Informed when a project decision has to be made.

This is a general look at how IT projects move through their life cycle. In a future post, I'll overlay the CLAP Framework, to pull together all of the concepts into a single view.

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

How to Achieve Your Goals - the ERRC Canvas

Illustration - the ERRC Canvas

 

As you might already know, I love canvases. They provide a simple means of communicating ideas. The image at left describes a very basic canvas to convey a very powerful idea: What do I have to do to achieve a Goal ?

In another BLOG entry, I will discuss Goals - specifically what makes good goals vs what makes difficult goals. If you want to do some homework, in a future BLOG I will discuss SMART Goals and why they are effective.

In general, and especially true in Business and IT, Goals can be achieved by placing tasks into one of four broad categories - Eliminate, Reduce, Raise, Create. Let's take a closer look at these simple yet powerful concepts. But remember, Goals are only important as a means of realizing a Strategy. Often, strategies are realized through the successful completion of a number of goals. Equally, there may be more than one Strategy being realized !

Eliminate - this is a pretty straightforward concept. Ask yourself the question "What do I need to remove from the environment to achieve the Goal ?". It could be simple, like lets eliminate duplicate services. If two systems can service the same Business Activity, then one of them is redundant. Ergo, one of them could be eliminated & help achieve the Goal.

Reduce - this is also a simple concept. If the Goal is to "decrease server sprawl", then the use of a consolidation solution (think of server virtualization) would reduce the number of physical compute hosts required to service the the Business Activities. Implementing server virtualization reduces the number of server's required to host the workloads, realizing the Goal.

Raise - this often goes hand-in-hand with Reduce in that often reducing one element will raise another. In the above example, we looked at implementing server-virtualization as a means of reducing server sprawl. It also has the opposite effect of raising the rate of physical server utilization !

Create - This is the tricky one. What do I have to ADD to the environment to achieve the goal ? Fortunately, the context of these canvases is around achieving IT Goals, in alignment with Business Strategy. So you might create a new process for deploying the virtualized servers into the compute environment, perhaps to enable a new Business Activity.

Now, each one of these sections of the canvas can contribute to the overall goal, meaning you might have many entries in each quadrant, all in alignment to the goal. This helps develop a list of activities which might need prioritization & dependency-mapping in order to complete. But at least now you have a defined method of achieving the established goal !

 

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

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