The Industrial Engineering of Business Service Factories
Jan 24, 2011 5:00 AM PT
The role and importance of private cloud infrastructure models has now emerged as a stepping-stone to much-needed new general operational models for IT.
Even a lot of the early interest in cloud computing was as much about a wish to escape the complex and wasteful ways of the old than as an outright embrace of something well-understood and new. Cloud computing may then well prove a catalyst to needed general IT transformation.
This cloud effect should force even the largest enterprises to remake themselves into business service factories. It's a change that mimics the maturation of other important aspects of business over the decades. Modernizing IT -- via Internet-enabled sourcing that better supports business processes -- comes in the same vein that industrial engineering, lean manufacturing, efficiency measurement, just-in-time inventory, and various maturity models revolutionized bricks and mortar businesses.
So the burning question now is how to attain IT transformation from current moves to leverage and exploit cloud computing? What are the practical steps that can help an organization begin now? How can enterprises learn to adopt new services support and sourcing models that work for them in the short- and long-terms?
By recognizing the transformative role of private cloud infrastructures, IT leaders can identify and justify improved dynamic workloads and agile middleware that swiftly advance the process of IT maturity and efficiency.
To discuss how modern workload assembly in the private cloud provides a big step in the right direction for IT's future, BriefingsDirect joined Paul Fremantle, the UK-based chief technology officer and cofounder of WSO2; and Paul O'Connor, chief technology officer at ANATAS International in Sydney, Australia. The discussion is moderated by Dana Gardner, Principal Analyst at Interarbor Solutions.
Listen to the podcast (46:04 minutes).
Here are some excerpts:
Paul O'Connor: It's unfortunate, but it's fair to say that all of the past initiatives that we tried in large, complex enterprises have been a failure. In some cases, we've actually made things worse.
Large enterprises, at the same time, still have to focus on efficiency, agility and delivery to their end users, so as to achieve market competitiveness. We still have that maniacal focus on delivery and efficiency, and now some new thinking has come in.
We serve the Asia-Pacific region and have focused for a number of years on next-gen architecture -- technical architecture, enterprise architecture and service oriented architecture (SOA). In the last couple of years, we've been focusing as well on cloud, and on how these things come together to give us a shot at being more efficient in large complex enterprises.
Specifically, we [as an industry now] have cloud or the Everything-as-a-Service operating model coupled with a series of other trends in the industry that are being bolted together for a final assault on meaningful efficiency. You hit the nail on the head when you mentioned industrial engineering, because industrial engineering is the organizing principle for weaving all of these facets together.
When we focus on industrial engineering, we already have an established pattern. The techniques are now lean manufacturing, process improvement and measurement of efficiency, just-in-time inventory, maturity models. Ultimately, large enterprises are now approaching the problem effectively including cloud, including moving to new operating models. They're really focusing on building out that factory.
Paul Fremantle: We've discovered that you cannot just build an IT system or an IT infrastructure, put your feet up, sit back and say, "Well, that will do the business," because the business has learned that IT itself is transformative and you have to be pushing the boundaries in order to compete in the modern world.
Effectively, it's no longer good enough to just put in a new system in every 5 or 10 years and sit back and run it. People are constantly pushing to create new value to build new processes, to find better ways of using what they have, linking it together, composing it and doing new things.
So the speed of delivery and the agility of organizations have become absolutely key to their competitiveness and fundamentally to their stock price. A huge move in agility came first with Web, with portals and with SOA. People discovered that rather than writing things from scratch, they could reuse, they could reconfigure, and they could attach things together in new ways to build function. As they did that, the speed of development and the speed of creating these new processes has skyrocketed.
I'm a firm believer that the real success in cloud is going to come from designing systems that are inherently built to run in the cloud, whether that's about scale, elasticity, security, or things like multi-tenancy and self-service.
The first and most important thing is to use middleware and models that are designed around federated security. This is just a simple thing. If you look back at middleware, for example message queuing products from 10 years ago, there was no inherent security in them.
If you look at the SOA stack and the SOAP models or even REST models, there are inherent security models such as WS-Trust, WS-SecureConversation, or in the REST model things like SAML2, OAuth and OpenID. These models allow you to build highly secure systems.
But, however much I think it's possible to build secure cloud systems, the reality is that today 90 percent of my customers are not willing or interested in hosting things in a public cloud. It's driving a huge demand for private cloud. That's going to change, as people gain confidence and as they start to protect and rebuild their systems with federated security in mind from day one, but that's going to take some time.
Those concepts of building things that run in the cloud and making the software inherently cloud aware, comes back to what Paul O'Connor was talking about with regard to having the right architecture for the future and for the cloud.
O'Connor: When we say better architecture, I think what we are talking about is the facets of architecture that are about process, that are about that how you actually design and build and deliver. At the end of the day, architecture is about change, and it must be agile. I can architect a fantastic Sydney Opera House, but if I can't organize the construction materials to show up in a structured way, then I can't construct it. Effectively, we've embraced that concept now in large enterprises.
Specifically in IT, we find coming into play around this concept a lot of the same capabilities that we've already developed, some of which Paul alluded to, plus things like policy-based, model-driven configuration and governance, management and monitoring and asset metadata, asset lifecycle management types of things relative to services and the underlying assets that are needed to actually provision and manage them.
We're seeing those brought to bear against the difficult problems of how might I create a very agile architecture that requires an order of magnitude less people to deliver and manage.
It helps with problems like this: How can I keep configured a thousand end-points in my enterprise, some of which might be everything from existing servers and Web farms all the way up to instances of lean middleware like WSO2 that I might spin up in the cloud to process large workloads and all of the data associated with it?
Also, you're not allowed to do anything in large enterprises architecturally without getting past security. When I say get "past security," I'm talking about the people who have magnifying glasses on your architectural content documents. It's important enough to say again what Paul brought out about location not being the way to secure your customer data anymore.
The motivation for a new security model is not just in terms of movement all the way to the other end of the agility rainbow, where in a public cloud you're mashing up some of your data with everybody else's, potentially, and concerned about it going astray.
It's really about that internal factory configuration and design that says, even internally in large enterprises, I can't rely on having zones of network security that I pin my security architecture to. I have to do it at the message level. I have to use some of the standards and the technologies that we've seen evolved over the past five, six, seven years that Paul Fremantle was referencing to really come to bear to keep me secure.
Once I do that, then it's not that far of a leap to conceive of an environment where those same security structures, technologies, and processes can be used in a more hybrid architecture, where maybe it's not just secure internal private cloud, but maybe it's virtual private cloud running outside of the enterprise.
That brings in other facets that we really have to sort out. They have to do with how we source that capacity, even if it's virtual private cloud or even if it's tenanted. We have to work on our zone security model that talks about what's allowed to be where. We have to profile our data and understand how our data relates to workloads.
As Paul mentioned, we have to focus on federated identity and trust, so Identity as a Service. We have to assemble the way that processing environments, be they internal or external, get their identities, so that they can enforce security. PKI, and, this is a big one, we have to get our certificates and private keys into the right spot.
Once we build all those foundations for this, we then have to focus on policy-driven governance of how workloads are assembled with respect to all of those different security facets and all of the other facets, including quality of service, capacity, cost and everything else. But, ultimately yes, we can solve this and we will solve this over the next few years. All this makes for good, effective security architecture in general. It's just a matter of helping people, through forums like this, to think about it in a slightly different way.
Fremantle: I believe that the world has slightly gone backward, and that isn't actually that surprising. When people move forward into such a big jump as to move from a fixed infrastructure to a cloud infrastructure, sometimes it's kind of easy to move back in another area. I think what's happened to some extent is that, as people have moved forward into cloud infrastructure, they have tended to build very straightforward monolithic applications.
The way that they have done that is to focus on, "I'm going to take something standalone and simple that I can cloud-enable and that's going to be my first cloud project." What's happened is that people have avoided the complexity of saying,"What I really need to be doing is building composite applications with federated identity, with business process management (BPM), ESB flows, and so forth."
And that's not that surprising, when they're taking on something new. But, very rapidly, people are going to realize that a cloud app on its own is just as isolated as an enterprise app that can't talk to anything.
The result is that people are going to need to move up the stack. At the moment, everyone is very focused on virtual machines (VMs) and IaaS. That doesn't help you with all the things that Paul O'Connor has been talking about with architecture, scalability, and building systems that are going to really be transformative and change the way you do things.
From my perspective, the way that you do that is that you stop focusing on VMs and you try and move up a layer, and start thinking about PaaS instead of IaaS.
You try to build things that use inherent cloud capabilities offered by a platform that give you scalability, federated security, identity, billing, all the things that you are going to need in that cloud environment that you don't want to have to write and build yourself. You want a platform to provide that. That's really where the world is going to have to move in order to take the full advantage of cloud -- PaaS.
O'Connor: I totally agree with everything Paul Fremantle just said. PaaS is the name of the game. If you go to 10 large enterprises, you're going to find them by and large focusing on IaaS. That's fine. It's a much lower barrier of entry relative to where most shops are currently in terms of virtualization.
But, when you get up into delivering new value, you're really creating that factory. Just to draw an analogy, you don't go to an auto factory, where the workers are meant to be programming robots. They build cars. Same thing with business service delivery in IT -- it's really important to plug your reference model and your reference architectures for cloud into that factory approach.
You want your PaaS to be a one-stop-shop for business service production and that means from the very beginning to the very end. You have to tenant and support your customers all along the way. So it really takes the vertical stack, which is the way we currently think about cloud in terms of IaaS, and fans it out horizontally, so that we have a place to plug different customers in the enterprise into that.
And what we find is, just as in any good factory or any good process design, we really focus on what it is those customers need and when. For example, just to take one of many things that's typically broken in large enterprises, testing and test environments. Sometimes it takes weeks in large organization to get test environments. We see customers who literally forgo key parts of testing and really sort of do a big bang test approach at the end, because it is so difficult to get environment and to manage the configuration of those environments.
One of the ways we can fix that is by organizing that part of the PaaS story and wrap around some of the attendant next-generation configuration management capabilities that go along with that. That would include things like service test virtualization, agile operations, asset metadata management, some of the application lifecycle management (ALM) stuff, and focus on systemically killing the biggest impedances in the order of most pain in the enterprise. You can do that without worrying about, or going anywhere near, public cloud to go do data processing.
So that's the here and now, and I'd say that that's also supportive of a longer term, grand unified field theory of cloud, which is about consuming IT entirely as a service. To do that, we have to get our house in order in the same way and focus on organizing and re-organizing in terms of transformation in the enterprise to support first the internal customers, followed by using the same presets and tenets to focus on getting outside of the organization in a very structured way.
But eventually moving workloads out of the organization and focusing on direct interaction with the business, I think we will see larger appetites by the business for more applications and a need to put them into a place where they are more easily managed, and eventually, it may take 20 years, but I think you'll see organizations move to turn off their internal IT departments and focus on business, focus on being an insurance company, a bank, or a logistics company. But, we start in the here and now with PaaS.
Next is workload assembly. What I mean by that is that we need a profile of what it is we do in terms of work. If I plug a job into the wall that is my next-gen IT architecture, what is it actually doing and how will I know? The types of things vary. It varies widely between phases of my development cycle.
Obviously, if I do load and performance testing, I've got a large workload. If I do production, I've got a large workload. If I move to big data, and I am starting to do massively scalar analytics because the business realizes that you go after such an application, thanks to where IT is taking the enterprise, then that's a whole other ball of wax again.
What I have to do is understand those workloads. I have to understand them in terms of the data that they operate on, especially in terms of its confidentiality. I have to understand what requirements I need to assemble in terms of the workload processing.
If I have identify show up, or private key, I have to do integration, or I have to wire into different systems and data sources, all of that has to be understood and assembled with that workload. I have to characterize workload in a very specific way, because ultimately I want to use something like WSO2 Stratos to assemble what that workload needs to run. Once I can assemble it, then it becomes even easier for me to work my way through the dev, test, stage, release, operate cycle.
Fremantle: What we have done is build our Carbon middleware on OSGi. About two years ago, we started thinking how we're going to make that really effective in a cloud environment. We came up with this concept of cloud-native software. We were lucky, because, having modularized Carbon, we had also kernelized it. We put everything around a single kernel. So, we were able to make that kernel operate in a cloud environment.
That's the engineering viewpoint, but from the architecture viewpoint, what we're providing to architects like Paul O'Connor is a complete platform that gives you what you need to build out all of the great things that Paul O'Connor has been talking about.
That starts with some very simple things, like identity as a service, so that there is a consistent multi-tenant concept of identity, authorization, and entitlement available wherever you are in the private cloud, or the public cloud, or hybrid.
The next thing, which we think absolutely vital, is governance monitoring, metering, and billing -- all available as a service -- so that you can see what's happening in this cloud. You can monitor and meter it, you can allocate cost to the right people, whether that's a public bill or an internal report within a private cloud.
Then, we're saying that as you build out this cloud, you need the right infrastructure to be able to build these assemblies and to be able to scale. You need to have a cloud native app server that can be deployed in the cloud and elastically scale up and down. You need to have an ESB as a service that can be used to link together different cloud applications, whether they're public cloud, private cloud, or a combination of the two.
And, you need to have things like business process in the cloud, portal in the cloud, and so on, to pull these things together. Of course, on the way, you're going to need things like queues or databases. So, what we're doing with Stratos is pulling together the combination of those components that you need to have a good architecture, and making them available as a service, whether it's in a private cloud or a public cloud.
That is absolutely vital. It's about providing people with the right building blocks. If you look at what the IaaS providers are doing, they're providing people with VMs as the building blocks.
Twenty years ago, if someone asked me to build an app, I would have started with the machine and the OS and I would start writing code. But in the last 20 years we've moved up the stack. If someone asked me to build an app now, I would start with an app server, a message queuing infrastructure, an ESB, a business process server, and a portal. All these components help me be much more effective and much quicker. In a cloud, those are the cloud components that you need to have lying around ready to assemble, and that to me is the answer.
Dana Gardner is president and principal analyst at Interarbor Solutions, which tracks trends, delivers forecasts and interprets the competitive landscape of enterprise applications and software infrastructure markets for clients. He also produces BriefingsDirect sponsored podcasts. Follow Dana Gardner on Twitter. Disclosure: WSO2 sponsored this podcast.