Enterprise Architecture

It’s not just IT that slows down the business. In a recent study 20% of companies reported they have NO innovation strategy and more than 50% of companies reported that their innovation strategy was mis-aligned with their business strategy and that their culture poorly supported it [1]. However, if we look at the IT side of an organization we often see the same kind of figures: 70% – 80% of IT budget is used just to run and maintain existing apps [2]. Maybe that’s even explainable since starting a new IT initiative is often a bumpy road: 68% of all new software projects are NOT successful [3].

These numbers aren’t new. Why do we all know them and, yet, they seem to stay the same? The interesting thing is that business nor IT is denying the current state-of-affairs. IT and business are equally frustrated about the current situation in most companies. When asked “are you happy with how IT is proactively engaging with Business Leaders to drive innovation?“, 74% of the non-IT execs state they are unhappy and 70% of the IT execs [4].

It seems like it is time for change…

I think the next 3 steps will provide a way to really change these numbers…

Step 1: start to believe in an agile enterprise

It wouldn’t be strange if you accepted the status quo: change is difficult, change is slow, especially in a big company. However, that’s not how it ought to be.

I believe that successful Enterprises:
Are agile.
Can respond quickly to changes in the market.
Because all departments are fully integrated in the overall value stream.
They have a big vision, but operate in small steps.
And gather feedback continuously and early-on.
They always work back from the customer and let customer-value drive new initiatives.
They focus on eliminating everything that’s not contributing to the value stream.

I believe that such Enterprises need Apps:
Flexible and focused apps.
That perfectly fit the business.
They are easy to find.
And easy to access, from any device.
They have an integrated user experience.
Their lifecycle is agile.
They change along with the business.
Users are engaged and their feedback is processed fast.
New apps are build in a collaborative process involving all stakeholders.
And they are easily delivered to the selected user base.
They align with enterprise needs around security, integration, and governance.
Instead of slowing the business down, they drive business innovation.

Utopia?
“Live your beliefs and you can turn the world around.” (Henry David Thoreau)

Step 2: add a ‘new productivity platform’ to your enterprise architecture

If we really want to change the way IT supports the business, we need to change the way we build new apps and manage the lifecycle of apps. Most IT teams are struggling with the amount of work they have, often resulting in a “no” to the business if they demand new business functions provided in software. And let’s just not talk about the constant change of business processes and policies that need to be reflected in existing software.

According to Forrester analyst John Rymer, Java and .NET are often no longer the best choices for the fast delivery of new business applications. Instead, we need, what he calls, new productivity platforms, to speed-up initial application delivery and ongoing updates. He defines “new productivity platforms” as [5]:

Platforms that speed application delivery and ongoing evolution through: visual tools, hot deployment and continuous innovation, built-in administration and management, and active participation of business experts in application delivery.

In my view these platforms are a special breed within the Platform-as-a-Service (PaaS) category. I’d like to call this sub-category Application Delivery PaaS to emphasize the focus on the complete application delivery lifecycle and not just deployment (as unfortunately a lot of PaaS platforms do).

Figure 1 – The App Delivery Lifecycle (source)

Figure 1 shows the four important phases in the application delivery lifecycle. The phase at the top is about requirements capturing as a collaborative process among all stakeholders. This collaboration is continued in the next phase when the new ideas and requirements are converted into models (or existing model templates are selected to fulfil the wishes of the stakeholders). In this phase the focus is on highly productive, collaborative development using visual models. These models are 1-click deployed to a runtime environment where they are executed and become real apps (I dubbed this Model-Execution-as-a-Service in the past). The key in successful app delivery is to continue to the next phase and engage with users, listen to their feedback, and use that feedback to come up with new requirements, thereby continuing the next cycle.

The phases are not numbered on purpose. The only way to really improve app delivery is to create shorter feedback cycles to increase collaboration with all stakeholders within an app delivery project. Where you start doesn’t matter, the app delivery lifecycle is a continuous process in which each cycle is as short as possible. And yes, this process should fit in an overall agile process to be able to function in the way described above. Or, in other words: the agile process needs to be extended outside development, we could call this ‘enterprise agile‘.

In my opinion you should start to use an Application Delivery PaaS. The ‘agile enterprise’ as described in step 1 will become much more within reach.

Step 3: know what’s agile and what’s not

If you are an enthusiastic user of one of these “new productivity platforms” (an Application Delivery PaaS) you may think this is the way to go for all application development. Something along the lines of “if all you have is a hammer, everything looks like a nail” [6]. Don’t go that way.

These platforms aren’t good for everything. Their real value shines when used for applications that need to be agile, that change on a weekly or even daily basis. You probably don’t want to build your bookkeeping software from scratch using such a platform. You should look at your processes and applications and distinguish different categories. Gartner distinguishes between commoditized processes supported by commoditized applications (e.g. bookkeeping software in most organizations) and differentiating processes supported by differentiating apps. Differentiating processes are the processes of your organization that really distinguish you from your competition. These processes will probably change frequently and time-to-market is important.

Ron Tolido (CTO at Capgemini) describes it way more colorful in his whitepaper about the five different application lifecycles that address different IT dynamics in organizations [7]. He uses a transport metaphor to identify these five different application types:

• Trains: stable, robust, standardized, no customizations, lots of users.
• Buses: also relatively stable, but more flexible. Some organizations may choose to own or hire their own buses.
• Cars: much more agile, individualized means of transport. Owners will adapt and configure them.
• Scooters: lightweight, extremely flexible and individual method of transport. They can bring you anywhere and you can even rent them for just a day or so.
• The hub: connecting the above.

You need to address each of these application types in a different way. In short: buy standardized solutions for trains and buses. Build apps using an Application Delivery PaaS if you need cars and scooters.

Conclusion

To summarize:

1. start to believe in an agile enterprise, 
2. add a ‘new productivity platform’ (an Application Delivery PaaS) to your enterprise architecture, 
3. and know what’s agile and what’s not.

If you do so, I’m sure the numbers mentioned in the introduction will really start to change!

——————————-

[1] Booz & Company – 2011 Global Innovation 1000 Study

[2] “In IBM’s experience, the 70-80 percent figure is roughly correct; little funding is left for innovation” https://www.ibm.com/developerworks/mydeveloperworks/blogs/invisiblethread/entry/enabling_smarter_decisions?lang=en

[3] Chaos Report 2010 by the Standish Group

[4] McKinsey Quarterly Dec 2011

[5] John R. Rymer, The New Productivity Platforms: Your Solution To The AD&D Crunch. November 1, 2011.

[6] Abraham H. Maslow, The Psychology of Science, p. 15, 1966.

[7] Ron Tolido, From Train to Scooter – Five Application Lifecycles That Address Differing IT Dynamics Within Your Organization, 2011. http://www.capgemini.com/insights-and-resources/by-publication/from-train-to-scooter/