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

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

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

The Importance of Process

 

I haven't blogged in some time. Seems life can get overwhelmingly busy at times, and well - it has been some of those times ! I've been spending a lot of time lately working on things that are process-oriented. Seems that when organizations want to define the products and services they sell, they ignore the industry-accepted definition.

According to ITIL, a Service is made up of people, process and technology. All too often, the organization believes that they can simply purchase and implement a tool, and all of their problems will miraculously disappear. I am working with two clients, who are approaching their delivery of a Service differently.

The first client is a large player in the Energy sector. To date, they have eschewed the use of ITIL terms to define their IT Service, as it doesn't readily fit their model for doing business. How could they let IT tell them how to run their business ?

When this client wanted to clean up their IT monitoring systems, they chose to segment the work into business-identifiable Services. They presumed they could buy a tool, and their visibility into their IT Operations would magically improve. They have been profitably in business for decades, so surely their processes and people were fine ?

In examining the first Service, it became apparent that the technology they were employing was actually satisfying 90% of their needs. It seemed the issues came up after the monitoring system alerted to a problem. Multiple service tickets were generated, usually causing a firestorm of activity - usually within the wrong groups ! To exacerbate the issue, the groups weren't communicating. This meant there was almost always a large duplication of troubleshooting effort.

In the case of the first client, the processes which were initiated were the root-cause of their issues. The technology did what it was supposed to do: send an alert when a problem arose. The people simply followed the process and reacted to the alert in a timely fashion. Unfortunately the process didn't allow for communication and co-ordination of their efforts, leading to delays and confusion in the IT personnel.

The second client is a small services company. They are re-building the company from the ground up; I call it going back into startup mode. In so doing, they are examining the services they provide to their clients. From the very basest levels, they want to be able to create repeatable, sustainable & desirable solutions for their clients.

This is being achieved by turning everything they do into a "project", with somebody responsible for managing that project at the helm. Project Management 101 would tell us that the Project Manager is responsible for Resources, Timeline and Budget - does this sound like what a Management Team should be concerned about ? So whether it is a team which is conducting Research and Development on a new physical product, or the Marketing guy working on building a new web-site, everything is a project. This provides visibility into "who ?", "when ?" and "how much ?" questions.

What this also means is that the second client can begin to normalize their Operations. By treating everything like a project, they have a repeatable framework to follow. The standard body of documentation required for every project (Charter, Cost/Benefit Analysis, Project Plan, Work Breakdown Structure and Closeout Report) allows for repeatability. Need a tower built ? Here's the required artifacts. Need a portable antenna installed ? Heres the project plan.

This will allow the client to have very tight control over their operations. This leads to increased productivity of the resources, as well as predictability in their Finance department, in terms of budget and revenue. The Sales and Business Development people can look at an exisiting Project Plan and estimate for themselves roughly how long it should take to complete a project. Further, if they are simply repeating a pre-exisiting project, they can likely provide a pricing quotation on their own.

So in both cases, we are seeing how these two very different clients are approaching their issues by examining the Services they provide. And in so doing, they are recognizing the importance of having well-documented procedures for their people to follow. The technologies they employ are all but irrelevant.

Posted with Blogsy

Open Source Frameworks

I will immediately start by saying that I have shamelessly stolen the idea for this blog. Massimo Banzi is one of the original creators of the Open-Source hardware platform, called the Arduino. It allows an inventor to program the microcontroller to control whatever mechanical system in whatever fashion they want. Imagine budding tinkerers building their own stop-lights, or fashioning their own motor-control systems ! 

In his Ted Talk (found here: How Arduino is Open Sourcing Imagination ), Massimo discusses how the Arduino gives inventors and tinkerers alike the ability to build with their imagination, pretty much free from the constraints of having to know very much about the hardware. Whether its the Arduino or one of the other new platforms, inventors and imaginers are free to explore the creative side, without getting too bogged down in the nuts & bolts of the hardware.

 

I'm going to make a leap here, so follow along... Another one of my Blogs describes my IT Service Management project, and briefly describes the use of the ITIL Framework. The purpose of the ITIL Framework, and more importantly the ITIL Dictionary, is to provide a common language for IT people to discuss the work that they do, and the services they provide.

 

Here's the leap: Arduino provides a common platform for tinkerers, inventors and imaginers to develop & share their ideas. Be they heliostats or stop lights. Just like the Global Village Construction Set describes plans for building the 50 commonly-used tools for building a society, Arduino provides a common platform for building the tools that society needs to control things.

 

Are you seeing the theme ? Open Source projects are providing the "Common Platform" required to get big, important things done. Like controlling mechanical devices, or building a society, or defining how we look at computer systems. This is why Open Source is so important.

 

Posted with Blogsy

Rethinking Our Relationships

I was in North Carolina for three days of holiday over the weekend. Since the weather was sunny and warm, we decided to take a day-trip to the Outer Banks. This long strip of inter-connected islands is a summertime resort paradise. Endless miles of sand beaches and ocean surf provide plenty of opportunities for families to play beachside.

Unfortunately, a good many of the hurricanes that wash ashore in NC scrub the islands which make up the Outer Banks. Between high winds and rain, this area gets devastated on an regular basis. You see the effects in terms of the local architecture - all of the beachside properties are built on stilts ! The only thing on the ground floor is the storage for boogie-boards and beach chairs !

One of the casualties in Nag's Head, NC was a monument called Jennette's Pier. It extends a thousand feet out from the shore, and provides opportunities for sight-seeing and fishing. When a hurricane washed ashore in 2003, hurricane Isabel slammed the coast of North Carolina. The pier was washed out to sea - completely destroyed ! In 2009, a rebuilding effort was commenced.

The pier has been completely rebuilt. Some 300+ new concrete pilings were sunk into the seabed, built to withstand the forces of nature. On top of these pilings was built what can best be described as an ecological laboratory. You see, Jennette's Pier is under examination for Leeds Platinum certification.

A quick look at the pier shows off the three horizontal-access wind turbines, generating much of the piers requirements for energy. And one of the shade pavillions on the pier is covered with photo-voltaic cells for solar generation. But the use of renewable energy doesn't end there ! Next there are some eighty wells dug for use by the geothermal HVAC system. Finally, there are also a number wave-actuated generators, situated on the seafloor. As the surf comes in & out, these generators wave back & forth, generating up to 300 W of energy every minute !

Being a public facility, and funded solely by voluntary $2 donations, any opportunity to recycle is welcome. Most interesting to me is the sign in the public washroom, which depicts the toilet and reads "Please don't drink or bathe from this facility. This water is 100% reclaimed !". The same is true of the fish-cleaning stations along the side of the pier. Rainwater is collected in lage cisterns, and re-used for cleaning fish, deck-washing, vehicle washing, and yes - flushing the toilets !

While the pier was originally built to support local anglers, when it was rebuilt it was to become an educational facility. The effort to rebuild the prier provided an opportunity to "re-think" the pier, and it's relationship with the ocean and beach around it. Personally, I was delighted to see all of the green technology in use and described for the visitors.

 

Chasing Shiny Objects

Shiny Objects

As my ITSM project continues, I am once again forced to have a series of uncomfortable conversations with my client. It seems that a smooth-talking sales rep has convinced an Operational Manager that they can solve all of their "monitoring and alerting" problems by simply ripping out what they currently have, and implementing a shiny new solution !

Shiny Services

Another Operational Manager has been consorting with a local Services Provider, who promises that if my client simply outsources their monitoring & alerting to them, all the problems will go away. For a low monthly fee ! Just sign a PO Mr Customer, and we can get started right away !

What's a Service ?

Now remember that the ITIL definition of a Service indicates that it is comprised as People, Process and Technology. In the first instance above, it appears that Manager believes he can buy a shiny new object, and all of his problems will go away ! That might speak to the Technology, but delivers nothing for the people or processes. In the second instance, the Manager is hoping to be able to outsource to the Services company, thereby dealing with the people aspect. But the Technology, and possibly the Processes are not being addressed. As such, neither solution deals with the underlying desire to take a "service-oriented" view of the IT Operation.

So in order to address this project properly, we will need to address all three facets of a service: Technology, Processes and People. I have re-ordered them because that is the most logical to me. I see the steps as:

1. Interview the Executive Sponsors to determine what their objectives are. In essence, I like to ask "What business problem are we trying to solve ?"
2. Interview the Operations Managers to determine what they see as being success criteria for the project.
3. Interview the Operations Team Leads. They will provide deep knowledge of the environment, the tools, and the current processes.

Technology

These three sets on interviews will provide the information required for the first phase of the project : Information Gathering & Gap Analysis. The Gap Analysis artifact is the first real Deliverable of the project. Once complete the Gap Analysis will help define what Technology is suited for the overall monitoring needs.

Process

I am in the middle of developing a series of Process Diagrams. These are visual representations of the processes that Operations personnel must go through when a specific condition is detected and alerted upon. There are two diagrams per alert - current state, and desired state. Any gaps between the two are highlighted and root-cause analysis is applied. Typically, these types of exercises uncover communications errors, and/or inefficiencies in the processes.

People

Finally, the thorniest part of the project is examining the People on the various Operations teams. This gets sticky, because the objective is to examine whether or not the team members have the correct skills to perform the Future-State processes, with the tools highlighted in the Technology section. It is never intended as a criticism, but many teams feel threatened by this step.

Summary

So as you can see, an ITSM Project is a lot more than a discussion of how to monitor IT Infrastructure. It involves examining the People and Processes as well as the Technologies. Simply buying and implementing a shiny new technology won't adequately satisfy the objectives of delivering Service-oriented IT.

What's Next ?

In a future BLOG, I will examine the second phase of this project, which involves classifying the collected information into alerts and data-sets, with an eye to event correlation & reporting.