As published in Architecture & Governance Magazine, Issue 2-3
“Innovate! We need to grow!” thunders the CEO. Yet not much seems to happen. Efforts peter out, or just never really get started. Business as usual seems to remain the order of the day.
Enterprise Architects find themselves torn by the very concept of innovation. On the one hand, they find excitement in the thought of doing new things; on the other, “what will it break in our architecture?” and “what won’t we be able to do that we really wanted to do?” are pressing questions. EAs find themselves both for – and against – the speed of innovation implied by that thunder from the corner office suite.
Governance Often Gets In The Way
One of the legacies of the past few years is a pair of notions. The first is that IT spending must be reined in. Company executives constantly want to know “how much are our competitors spending?”, and then set spending limits below that amount. As a result, funds for innovation are lost as the costs of operating what is already in existence take up a larger share of the pie. The second, even more insidious, is the requirement to prioritize investments by their financial business case alone. This puts a premium on justifying incremental change, as opposed to the assumptions required in the case for something truly new.
To innovate successfully, our governance practices must evolve to allow for innovative ideas to not only emerge, but also get funded. Some of the more popular techniques used include:
Likewise, follow-on controls for innovation efforts turn on the question of whether ‘what they are designed to prove out is being proven out’, rather than ‘what is required to complete this on schedule (or on the new schedule.)’ The model for this type of control is found in pharmaceutical research: many efforts, with decisions to ‘kill’ the effort predominating.
Architecture Can Also Be A Roadblock
Oddly enough, even in organizations that have the appropriate governance processes to foster innovation, the EA process itself can become a roadblock. The paradox of this becomes even more apparent when we recognize that it is the organizations with well-developed and comprehensive architectures and EA competence that often end up stifling innovation most effectively!
In some ways, architecture and innovation are at opposite ends of the spectrum. Competent, solid architecture is often judged by its suitability over time; innovations thrive on the untested, the new, the ‘not yet approved’. (They need not be, of course, and innovations that have competitive advantage potential are often more about seeing the business model, the customer, or a product differently than depending on a new piece of technology. But the reality is that the existing application base and information architecture may well be ‘broken’ by an innovation even if the technology for deployment is all part of the technology architecture that exists.)
Professional EAs, therefore, inject the architectural process into the development of the innovative solution. The trouble is, the more comprehensively they do their jobs, the slower the innovative project is to start – and the more likely it is to compromise its innovation in ‘fitting in’ to the pre-existing environment.
EAs need to build in the capability to handle change. This works against architectural perfectionism – but leaves room for growth and the evolution of the IT base that the organization depends on. The goal is almost to treat the architecture as an ecosystem rather than an engineering task.
Who Is Going To Think Up These Brainstorms, Anyway?
Another issue that holds back innovation is people. Take a look around your organization. How many really innovative ‘idea people’ are there, anyway?
The reality is that the kind of people who are good at looking at situations, finding the deeper problem within them and then coming up with new ways of facing that challenge, is both rare – and often considered a liability most of the time. Such innovators are often labelled “hard to manage” or “off in their own world.” As a result, during every cycle of cutbacks, these are the first to be let go – and often the ones turned down for hiring. (The situation has been made worse by the move to major application packages over the last decade, as this has taken away this type of person’s most common residence in the organization: internal custom development.) EAs can, however, be of help in the innovation process. Some of the earlier stages of the enterprise architecture cycle itself – environmental scans, the development of an enterprise business architecture – are superb grounds for finding and developing the type of thinking required for innovation. Why not open up these processes to outsiders? Why not ask leading questions about business models, competition, existing solutions’ deficiencies and see who takes on these questions and really works with them? More so than with the relationship managers in the IT organization, the EAs do work that allows those who can innovate to “catch the bug”.
Properly embraced, the innovators can be an EA’s greatest allies. Consider your existing solution portfolio. How much of it would you like to see replaced? (And how much of an audience do you have for replacing it at any time in the near future?) Innovation can trigger an interest in application replacement and significant refurbishment that will make more of your planned architecture into an implemented one.
Consider the case of a retail banking institution. Although it had been through multiple recent mergers, by comparison to the others in its market, it was still a small player. A decision was made to innovate with a new type of mortgage product designed around the linkage between assets held by the institution, share-of-wallet for services and the amount of the mortgage to attract interest (as opposed to the total amount lent.)
The systems base was the usual hodge-podge of ten- and twenty- (or more!) year-old systems inherited from multiple mergers. This would have been a superb opportunity to refurbish or replace most of that portfolio. (The opportunity was lost, unfortunately.)
EAs at this institution could have proposed an evolutionary architecture. First, lay on a quick-and-dirty layer for the new product, then start simplifying and unifying the underlying pieces. This, in turn, would have paid off in the end with much lower run costs for IT – and a competitive base to build out the business over time.
Making room for innovation, in other words, can assist in many ways beyond the value of the innovation itself. Demonstrating delivery to the CEO on the CEO’s agenda will accelerate that set of changes. Isn’t that, at the end of the day, what EA is all about?