A business with ideas has energy and potential.  It can breed a culture of excitement, fun, and a sense that something big could happen that could change everything.  At the other end of the spectrum, there's the comfort and stability of something that truly works.  Don't break it and don't change it is more the feeling here.  It's not as fun, but it's something to rely on. While these two are worlds apart, they should, and often do, coexist in any business.  A new philosophy is emerging to help businesses better understand this and get better results.

Odds are, you've seen it in the past.  Rumors start spreading.  It goes something like this.

Someone on the front lines of the business or in the heart of business operations has an idea.  They believe they can do something new and innovative by crunching some data, calculating some interesting stats, or mining some type of particular pattern from something they know about the business.

It's uncertain, for sure.  A theory.  But they want to try to do something new.  They don't have the interest or energy to try to work through the 'process' with IT.  They don't want to try to 'make a business case' for some structured governance team to review for months.  The opportunity may even be time sensitive, requiring immediate action.

So, they go around IT altogether.  They start some type of undercover, off-the-radar, shadow development project.  They don't care about most of the things one cares about when developing typical enterprise-type solutions.  They just want to try something new and see whether they can do something interesting.  Unfortunately, since most organizations (IT organizations, particularly) frown on this, the effort is done underground.  It's funded somehow outside the IT budget, and it's kept relatively secret and separate from everything else and especially the IT pros of the business, because "if they find out what we're doing, they'll have a cow and insist that we follow their process and methodology and everything we're making progress on will go down the tubes."

There are two types of outcomes I've seen here.  

One is that someone truly brilliant has come up with something quite awesome.  They have some type of game changer.  The 'quality' of what they've done may not be production-ready, but the substance is there.  Ultimately, the innovative prototype grows into something significant, gets funding, is re-written with a more serious type of solution architecture and becomes something that truly works (i.e., one of those things you trust, 'don't break it and don't change it').

The other type of outcome is not nearly as pleasant.  Things blow up.  The wrong person, at the wrong time, gets wind of what's going on.  A huge conflict emerges.  A power play arises.  There's a showdown between IT and the business.  Ultimately, someone backs down (often the business) due to rhetoric about risk, disruption, controls, process and all sorts of scary things.  The prototype is killed, and nothing more is heard about it.

To be fair, IT governance, process and structured methodologies exist for a reason.  Without process and methodology, bad things happen to important stuff.  It can be a legal, compliance related matter.  It can be a fiduciary issue.  It can be life threatening (e.g., life support systems).

The problem here is that there's a spectrum of needs for solution development.  Unfortunately, IT generally controls the plan for governance.  After all, no one else understands all the gibberish they talk about.  As a result, governance is designed for the principal concerns of IT, which is the important systems that the business relies on every day to make the business work.  These are the systems that keep the important 'records' of the business.  This is where customer data and transactions are recorded.  This is what drives customer billing.  This is important stuff, and it must be protected.

A one-size fits all approach to IT governance often doesn't provide for the needs of those wanting to prototype and innovate.  In fact, it struggles to facilitate the needs of another class of applications that truly differentiate the business.  These are the systems, somewhat unlike the important systems of record, that make the business what it is.  These systems do change and they need to be able to change, in a controlled way, to respond to opportunity and competitive threats. 

The Gartner Group has introduced the concept of Pace Layering, encouraging us to not only acknowledge that things need to change at different paces, but also to embrace a strategy for IT governance that fosters innovation alongside prudent change control.

Here's the basic idea.

There are three "Pace Layers": Systems of Innovation, Systems of Differentiation and Systems of Record.

Each of these layers relates to a distinct need for rate-of-change and quality of results.

The idea is that all applications and all development activity should be organized onto one of these layers.  Each layer is designed to have appropriate rules and controls for an application with the corresponding need for change and quality.

Systems of Innovation are the applications and prototypes that drive new and experimental activity.  This is where one needs to be able to quickly get something done, try new approaches, and so forth.  It needs to allow for rapid change, allow for the use and application of any type of technology and should be mostly an anything-goes mentality.  It needs a budget, and it needs to be encouraged because this is where your next 'big idea' or game changer comes from.  Many efforts in this category simply won't make it long term.  Some will, and if so, they will likely move to another layer at some point.

Systems of Differentiation are the applications that truly make your business what it is.  This is your unique product or service.  Without applications that provide something unique in this layer, your business would be exactly like any other business in your industry.  These applications are important, but they also need to be able to change to respond to regulatory or statutory change or simply changing market conditions and customer demand.  However, the change in these systems must be planned, carefully executed, well tested and reliable when released to production.

Systems of Record are applications that are fundamental.  This is often the accounting or ERP backbone of your company.  In many cases these will be large complex systems that have been purchased from major vendors (e.g., a health information system at a hospital).  Some of these may be home grown, but they are considered a foundational part of the business, where access to data is highly controlled, carefully managed, must be of the highest integrity and loss of data here would be catastrophic.

By providing an IT governance strategy that is adapted to the needs of these different layers, an organization can bring innovation out of the shadows.  By acknowledging the importance of this activity, those with the ideas to innovate can gain support.  Imagine how helpful it could be for a business guy with an idea to be able to legitimately do an innovative prototype, openly collaborating with IT resources with the skills they need to get their prototype done quickly.  Imagine how refreshing that would be for the IT resource, getting a chance to do something in a less structured environment, from time-to-time.

I believe that current realities and consequences of the last decade of process infusion have created this new pace layering philosophy.  Businesses need results AND they need carefully controlled stable systems.  To the chagrin of the best IT management teams, shadow activity continues to emerge, go against the sanctioned platforms and processes, and dad-gum-it, sometimes produce undeniable successes.

The real opportunity for IT lies in embracing the potential of pace layering and providing the necessary infrastructure to make this possible.  After all, just because an application is an innovative prototype that doesn't mean that it can have unfettered access to all enterprise data.  Quite the contrary.  An enterprise architecture is needed to allow for easy (conceptually easy), but controlled, access to data and methods in Systems of Differentiation and Systems of Record layers.  Thinking ahead that someone is going to want to access data from VBA, PHP, Python or something else will provide unique challenges for the IT team to solve.  Doing so, however, will position your business to innovate and win over its competitors.

So, as you see the struggles occurring in your organization, and as you, perhaps, observe the scenarios playing out that I described above, consider how pace layering could get everyone on the same page.  Imagine a governance model allowing for a full spectrum of activity in your business from the innovative to the rigorous.  With a language and model that fits, tension could be eased on both sides of the fence with the excitement, energy and fun of innovation occurring alongside important, carefully controlled, predictable and stable activity.  At the end of the day, it's about fostering success and results.