reference architecture

First internal clouds likely to fail, Forrester says

I have worked with a lot of corporate data centers and believe me, this is so true. They have a lot of learning to do when it comes to virtualized and shared infrastructure. They have generally been smart and quick learners though so I am sure that they will eventually get there. Patience will rule the day.

First internal clouds likely to fail, Forrester says

Innovation in the Business of Government: A GSA Blog

From the CIO of the General Services Administration - Around the Corner by Casey Coleman.

Cloudiness and reality

Mark Gibbs touches on an important consideration related to using “Cloud Computing” in his Cloudiness and reality article.

It is the distinction between outsourcing the tasks associated with your infrastructure-as-a-service, platform-as-a-service, or software-as-a-service and outsourcing the governance and responsibilities for your systems.

As long as you are responsible for any part of the governance or availability of your outsourced systems then you have retained the bulk of the work that goes into managing and overseeing those systems.

Being an Enterprise Architect

Dana Bredemeyer presented "What it Takes to be Great in the Role of Enterprise Architect" at the Enterprise Architecture Conference in October 2002.

Clinger-Cohen Competencies for Enterprise Architecture (2008 Update)

"DoDAF Version 2.0 Plenary Architecture Education & Training" presentation, U.S. Dept. of Defense, 8/17/2009.

Goals and Tools

According to a study by the Center for Studying Health System Change, a "Gap Exists Between Vision for Electronic Medical Records (EMRs) to Improve Care Coordination and Clinicians' Experiences."

The study found that commercial EMRs are better at meeting billing and documentation needs than clinical needs.

"This work emphasizes that improving care coordination will not happen with technology alone," said Commonwealth Fund Vice President Anne-Marie Audet, M.D. "What is needed is a redesign of care processes and work flow; clinicians will also need to adopt new ways of working and communicating within practices and across organizations."

As I have written before, Goals and Tools. It is not the tool makers responsibility for meeting business goals. It is the practitioner's responsibility for utilizing and taking advantage of the tools on hand to improve and optimize their outcomes. Even if it requires changing the way they work.

Business Success and Technical Tools

Are you in a business support role? This is those roles that aren't directly involved in selling, delivering, and supporting products and customers. For example, roles like information technology, quality, auditing, legal, procurement, human resources, and accounting.

Do you have any of your own projects, or, do you play a supporting role in "business" sponsored projects?

How are the goals for the project defined? Who is responsible for the outcome of the project? What metrics are used to measure success?

Business sponsored projects must have business goals. For example, implementing a software package is not a business goal, it is a functional goal - the function of Information Technology. Measuring product quality is not a business goal, it is a functional goal - the function of Quality. Employee evaluation and ranking is not a business goal, it is a functional goal - the function of Staffing. Functional goals can be successful and yet the project can still be a business failure.

Projects and goals must be defined and executed in terms of benefits to the customer. If the goal is to shorten the sales and delivery cycle then the sales force automation software is only a tool. Tools do not replace smart and dedicated workers. It is these employees that leverage the tools available to them to achieve their goals. The responsibility for success falls squarely, in this example, on whoever is responsible for the customer relationship.

The "The Secrets of Software Sucess" by Chris Dowse in CIO Insight magazine mirrors my experience over many years now. He doesn't say it outright, but I will repeat what I have told many company executives with failing software projects. "The business must take responsibility for and own the success/failure of the business purpose for the software project."

I believe that one way that this can be facilitated is to separate governance from implementation and support. A corporate level governance team should own strategic and politicized responsibilities like enterprise architecture, portfolio governance, and process automation.

The technology implementation and support team should provide the technology services and tools and protect the data (wherever it may be) in a utility-like fashion.

 

Simplicity versus Complexity

[Note: Originally posted on "improving outcomes blog" on 2Mar2010.]

Simple is hard.

It is much easier to do things the complex way. It takes very little thought about what you are doing or how you are doing it if you don't care about the complexity of the process or the resulting product.

As Abraham Lincoln said, “I'm sorry I wrote such a long letter. I did not have the time to write a short one.”

Mark Twain is also quoted as saying, "I didn't have time to write a short letter, so I wrote a long one instead." [update 8/23/10]

So, if complex is easier and faster, and simple is harder and takes longer - why do I want to simplify?

As I have discussed in previous posts - it comes down to the difference between ad-hoc and repeated-use processes and products. The difference between designing/optimizing and executing/maintaining.

If a process is performed just once or if there is only a single implementation of a product then there is little benefit to simplicity. These are truly ad-hoc processes and products.

For everything else, the answer is quality. Quality attributes like functionality, reliability, availability, usability, efficiency, maintainability, and extensibility.

It is hard to get the results you want on a reliable and repeatable basis using complex processes and products. Complex processes and products have more failure points and break down more often than simple ones. And, when they break down it is difficult to find the root cause of the error and fix them. It is also very hard to learn complex processes and products and become efficient using them. Finally, complex processes and products are difficult to modify or extend to support changing needs.

Where does complexity come from? It can creep into your processes and products in many ways. A few ways are:

• Converting ad-hoc processes to organizational processes.

• Designing without the real end-user in mind.

• Layering governance processes onto organizational processes. This is also know as the bureaucracy factor.

• Poor implementation, including training, of organization processes.

Two key approaches to remove complexity are:

• Design all processes and products with the focus on the end-user. Understand the needs of the end-user and meet those needs as simply as possible.

• Only add tasks, features, and functionality to your process and products that are absolutely required. Also, remove any that are no longer required. Leaving unnecessary bloat in your processes and products are a big cause of complexity.

References:

1. Harvard Business Publishing Webcast - Take Complexity Out of Your Company, with Ron Ashkenas, author or Simply Effective.

Business Process Mangement (BPM)

[Note: originally published to "improving outcomes blog" on 8Feb2010.]

Business process management (BPM) is the study of the design and execution of processes. A business process is a step-by-step algorithm to achieve a business objective. Business processes are viewed as assets to be managed, designed, and continuously improved to enhance business agility and operational performance. BPM includes modeling, executing, and monitoring business processes to achieve optimum outcomes.

Benefits of BPM:

• help organizations move from being operationally focused to being customer focused
• formalize existing process and spot needed improvements
• help business leaders identify which processes can benefit most from becoming more agile
• create a shared perspective on how multiple functions contribute to the entire end-to-end process
• help organizations move from operational silos to become focused on the end-to-end process (more customer-centric)
• facilitate automated, efficient process flow
• increase productivity and decrease head count
• allow people to solve the hard problems
• simplify regulations and compliance issues

According to Andrew Spanyi (Spanyi, 4/2008) you know that you need BPM when:

• Processes involve many complex steps
• The business lacks process control and auditing features
• Exception conditions are handled inconsistently
• Transactions are plagued by high error rates
• You can't view and track all process-related data and documents
• Information flows slowly or inconsistently across the organization
• Disparate IT systems are in need of integration
• Processes require manual paperwork
• Work in progress can't be traced across multiple departments
• Reporting on work steps and end-to-end processes is cumbersome
• Decisions take too long

A BPM system is a set of integrated technologies that enable process stakeholders and users to model, execute, and monitor business processes to achieve optimum outcomes. Complete systems include technologies for managing all aspects of the business process; people, machines, information, business rules, and policies. BPM systems are process-oriented applications.

Benefits of BPM systems:

• BPM initiatives place primary responsibility for process management on the shoulders of the business units – where it belongs.
• puts the capabilities to design and manage processes into the hands of the business leaders
• makes a process explicit - gives visibility of the end-to-end business processes and enables business leaders to make adjustments in real time
• provides the ability to continuously optimize and improve the process
• abstracts the business process flows from the underlying technology (separates process model from implementation)
• can help break down application silos and automate more of the end-to-end process
• provides greater leverage of existing assets, rather than simply making new software investments

Some best practices for BPM projects are:

• highly iterative
• eliminate project disconnects
• assign a core team
• select the right BPM system
• embrace top-down discovery sessions
• start with current state process model before making enhancements
• immediate core team training

In the Building A Service Delivery Model for Enterprise BPM case study the authors discuss setting up a Center of Excellence for Business Process Management at Merrill Lynch. A lot of this is pretty standard but I liked how they grouped their requirements in a set of common themes and then carried these themes forward through the remaining phases. The common themes that they identified are:

• Competency Analysis
• Governance
• Collaboration Improvement
• Technology Improvement
• Process Management

There are also a number of example templates that are useful if you don't already have something in place.

(This information has been gleaned from a number of sources over time. I don't have the exact sources for all of it but they include Gartner research, Forrester research, IBM documentation, and BEA/Oracle documentation.)

Dynamic versus Static

[Note: originally posted on "improving outcomes blog" on 26Jan2010.]

To facilitate business opportunities, all departments and functions must remain dynamic. We live in a time of massive global change and uncertainty. Thinking that you can remain static while everything else changes is a risky position.

Static linear processes must become dynamic, parallel and event driven. Decisions need to be local and framed with strategic planning, balanced scorecards, and operational frameworks. Rules must be replaced with guidance. Information needs to become free of silos and fiefdoms.

In Strategic Plans Lose Favor: Slump Showed Bosses Value of Flexibility, Quick Decisions by Joann Lublin and Dana Mattioli (WSJ, 25Jan2010) they report that "strategic planning doesn't always work" and "Strategy, as we knew it, is dead." They equate strategic planning with "distant calendars and rigid forecasts of the past." I disagree that strategic planning involves static tactical plans and forecasts. To me, strategic planning provides guidance to the company while getting business done. It points everyone in the same direction. It provides input to tactical plans, but so do up-to-date financial statements, market forecasts, and the economic climate.

(Update: 3Feb10) Harvard Business Publishing Webcast - Understanding Your Strategic Purpose, with Nikos Mourkogiannis, author of Purpose: The Starting Point of Great Companies. Nikos explains the higher concept of purpose, which is starting point of strategy.

New research by Insights Learning and Development and the Project Management Institute suggests that the single most important factor influencing project success is its link to the organization's business strategy.

Dynamic, parallel and event driven business processes aren't enough. You need to make sure that the planning, governance, and quality processes that support those business processes are just as dynamic. To capitalize on new business opportunities you need to be able to acquire, develop, deliver, and manage the necessary resources. And, the more innovative your new product or service the more dynamic your sourcing capability needs to be.

Cloud Storage Service Tests

Network World has published test results of Amazon's S3, Rackspace's CloudFiles, Egnyte's On Demand File Server, Nasuni's Cloud Storage, and Nirvanix's Storage Delivery Network cloud storage services.

On the good side they found that cloud storage can be fast and pay-as-you-go can be a real cost saver.

On the bad side they found that security could be an issue for enterprise customers and, my #1 complaint, the formulas for trying to predict overall costs can be complex.