2 Comments

Summary:

IT departments have historically feared complexity because it implied creating systems they couldn’t afford. Now, in the age of cloud compute, it’s not just possible to make complex IT — it’s essential in order to ensure products and services are delivered ahead of competitors.


Transcription details:

Date:

19-Jun-2013

Input sound file:

1003m

Transcription results:

Session Name: The Composable Enterprise

Announcer Jonathan Murray

Announcer 00:06

Thank you for that. Our next presenter is Jonathan Murray with the emphasis today on green and sustainability. Jonathan is going to be talking about the Compostable Enterprise. I’m sorry, the Composable Enterprise which is a little bit different, I suppose. [laughter] Those who don’t know Jonathan, he actually spends his time somewhere between Vienna and New York, and other various parts. He’s Adamalthus on Twitter for those of you who want to follow him. He’s one of the deepest thinkers in the Cloud that there is. Please join me in welcoming him.

Jonathan Murray 00:54

Good morning. Thank you for a few minutes to share an idea, and thanks, Joe, for the introduction. This idea is sort of borne by a couple of decades of working with some of the largest enterprises in the world. And both working for and with those companies. One of the challenges we have as businesses today is living in a constant state of flux. Markets change, our competition changes on a daily basis, consumer demand changes. We have to constantly innovate new generations of services to keep ahead of our competition. The ideal solution for that would be a composable enterprise, an enterprise that is based in a set of building blocks that can be re-figured on demand as needs change. A dynamic organization, one that’s flexible and responsive. There are major challenges in delivering something as adaptable as that. We know the challenges that most organizations face today.

Jonathan Murray 02:10

One of the biggest challenges we have is actually operating at the speed of business. The world moves very fast and our organizations don’t move fast enough. That’s the reality that most large enterprises face today. The biggest reality that most organizations face today is that IT is the biggest barrier to change. The backlog that most organizations in their IT organization is a huge challenge to evolving, adapting, and being agile as an organization overall. That’s the biggest challenge that most CIOs face. The most important metric I would suggest to CIOs today is time-to-value. It’s not cost control. It’s not the budget management. It’s how quickly you can deliver capability to meet the needs of a constantly changing business. Yet, this is the reality of most of the infrastructures that most enterprises deal with. I’m a practitioner. I’m in an organization today that is struggling to deal with 40 years of legacy infrastructure development. Islands of automation that were developed, that were put together with no concept of ever working together as connected systems. As the business changes, we wire those systems together. We build point-to-point connections. We end up with a highly coupled very fragile infrastructure that is not resilient. It’s subject to cascade failure. You move one piece of the puzzle and the whole thing falls apart. That is really the reality of many large organizations today. This is how we built IT systems for the last 30 years. Every system is different, the plumbing is different, the wiring is different, the infrastructure is different. Then, we try and put them all together into something that works. In the world today, where services and service innovation is one of the key drivers of competitive performance in the global market, you need to wire those systems together. We’re now in a business where horizontal integration is the key driver of business performance.

Jonathan Murray 04:34

Yet, we built systems that were never designed to be integrated horizontally. This is how we should be building systems. This is how we should be building enterprise architecture, apartment blocks where there are common, shared services. Where you get the same electrical connections in every room. Where you get the same plumbing throughout the building. Where each room can be configured, the room being an application. The business can decide how it wants that application configured, but all of those applications share a common horizontally-integrated infrastructure. Now, why do we build systems the way we do? Why have we built them the way we have for the last 30 or 40 years? The reality is that we have been living in an environment where the raw materials of IT – compute, storage, memory, etc. – have been scarce, expensive resources. Every time we’ve built a system, we’ve had a design blueprint that is all about optimizing for the utilization of those scarce, expensive resources. There’s a reason that we put stored procedures into databases. Because, databases and data storage was an expensive thing. You had to squeeze every ounce of performance out of that system. We’ve lived in an era of scarcity. Yet, in 2006, Amazon changed that paradigm. Amazon was literally the first company that basically was betting on the fact that we were moving from the era of scarcity to an era of abundance. Where the basic computing resources that we build systems from are not scarce and expensive, but actually almost infinitely abundant and cheap.

Jonathan Murray 06:41

There was no technological transformation, there was a business model transformation. This was a company that finally decided that we’d reached a point where you could become a true utility provider of infrastructure. Obviously, Amazon placed a very serious bet in 2006 in the ability to do that. One of the things that you understand about complex systems is that they are both productive and they’re resilient. Ecosystems are better when they’re more complex. They’re more resilient. Yet, we as IT professionals have spent the last 40 years fighting complexity. We fought complexity because when you build tightly coupled systems, complexity is a problem. It can create cascade failures. It can create fragility, so there’s got to be a new way of building a new generation of architecture. A new generation of applications that embrace complexity, that get the advantages of an emergent innovation, out of complex environments, but at the same time resilient and flexible. Is there a light at the end of the tunnel? At least one person’s opinion is yes. And that light is what I call Cloud Architecture. Now, Cloud to me is sort of like the Wizard of Oz movie, right? In the Wizard of Oz, there’s the shining Emerald City. It looks really great. We talk about it. It has a particular image and then actually when you get down there, there’s a set of curtains and behind the scenes there’s somebody mechanically moving all the pieces. Cloud isn’t Amazon. It isn’t a deployment model. It isn’t private versus public. Cloud is an architectural blueprint for developing a new generation of loosely coupled, highly resilient and scale-able systems. A set of composable systems that can be reconfigured on the demands of the business.

Jonathan Murray 08:59

What’s the journey that an enterprise has to take in order to take advantage of this new architectural blueprint? The first thing is decoupling applications from infrastructure. That’s one of the reasons I’m such a huge proponent of platform as a service, as a framework for abstracting the infrastructure from the application layer in an architecture. We’ve made a big bet on Cloud foundry, but there are plenty of other options out there today that enable that decoupling. That’s the first stage for me. You’ve got to move to an environment where when you build an application, you’re not making an infrastructure decision every time you build that application. The next thing is making data a service. Every piece of data that you use in an organization, whether it’s your master data, they need to be single sources of truth for all your master data in an architecture. Every important piece of data that you want to consume needs to be consumable through a service layer. If you can’t do that, than you’re back to building tightly coupled, hardwired systems. Finally, you’ve got to decompose applications. We think of applications, historically, as these monolithic things. They’re a whole solution that we developed to serve the needs of a particular business unit or function. What you need to do in these new architectures is break an application down into its component pieces, into the set of services that make up that application. Because what you want to accomplish at the end of the day is delivering the needs of the enterprise with the minimum software footprint you can possibly do. That means figuring what services sit in which applications can be shared between different applications. Getting into that decomposition is a really important piece.

Jonathan Murray 10:54

The final piece of the puzzle is to automate the heck out of everything. There is no reason today why an enterprising running its IT infrastructure should require any more human resource in scale than either a Google, an Amazon, or a Microsoft do for running their highly scaled, highly automated infrastructures. If you look at most IT budgets, the biggest slice of the pie is actually people cost. An organization’s people tweaking around on operating systems, keeping Unix systems or Linux systems up and running, that has to go away. We need to run on highly automated fabrics. The payoff is pretty straightforward. Lower operational costs because you’re automating and streamlining the ability to deliver new capability to the business. You’ve built, if you accomplish this, an innovation platform for the business. If experimentation doesn’t cost you very much and it’s disposable, than you’re going to experiment a lot more. The problem with most infrastructures today in most organizations is the cost of experimentation is extremely high. So, we don’t experiment very much and we’re very afraid of failure because the cost of failure is expensive to the business. We need to create environments where businesses innovate in services, new product delivery, etc. at very high rates at very low cost.

Jonathan Murray 12:30

The final piece of the puzzle is building an environment that lowers time-to-value. Literally, I’ve chosen this picture for a reason. As IT professionals and IT organizations, we need to evolve away from IT being a craft to IT being a factory. The only way IT organizations are ever going to accomplish and overcome the backlog that every IT organization in the world faces, is to build a factory floor. It to build an infrastructure that allows new capability to be delivered to the business in hours, days, and weeks and not months and years. This new ability, these new architectures give us the ability to do that. So, this all sounds like fairy dust and unicorns, right? Seems like a really challenging thing to pull off. Over the last eight months, my organization has basically delivered everything I’ve talked about on this slide and in this presentation. We have that new fabric. We have production applications running in that environment today. We’re starting to see very real benefits from doing that. If you want to know more, this is how to get hold of me. Thank you very much indeed.

firstpage of 2
  1. justinnemmers Wednesday, June 19, 2013

    Spot on. I really see innovation lacking as a result of forced vendor standardization. IT organizations really should be able to chose the best tool for the job. Shoehorning tools into ill-fitting problems often does end up costing more– largely as a result of (as you say) the “legions of admins” required to effectively support it. A “more tools” philosophy is not always wrong, and can, in fact, help organizations improve upon that dreaded requirement of cost control when properly managed. I heard this message over and over again from the hundreds of IT orgs I spoke with at last week’s Red Hat Summit. See point #3 in my blog: http://info.cloudboltsoftware.com/blog/bid/306535/7-Takeaways-From-the-Red-Hat-Summit

    Share
  2. quoteworld.org: “If builders built buildings the way programmers wrote programs, the first woodpecker that came along would destroy civilization.”
    — Author Unknown
    Has that changed? I don’t think so. Treat programmers like interchangeable parts and customers will end up treating your business the same way.

    Share

Comments have been disabled for this post