CTO Q&A: Self-Service Private/Hybrid Cloud Coalition
newScale, rPath and Eucalyptus Systems have announced a self-service private/ hybrid cloud offering delivered by MomentumSI.
This coalition brings together three foundations as a basis for an enterprise cloud:
1. Self-service
2. Automation
3. Elasticity
I had a chance to sit down with principals from each organization for perspective on what this coalition means to them, and to the broader market.
The following is an excerpt from a conversation with Jeff Schneider, CEO of MomentumSI; Rich Wolski, founder & CTO of Eucalyptus Systems; Erik Troan, founder & CTO of rPath; and Rodrigo Flores, founder & CTO of newScale.
Q: Jeff, what makes this combination of particular interest to enterprise IT today?
A: IT is being held to higher standard for speed, responsiveness and cost-efficiency in part because of the rise of public cloud services, which have become both the context and example for what IT must become, as well as a potential alternative to IT organizations that fall short of this new standard. This is both a risk and an opportunity for enterprise IT today. The combination of self-service, automation and elasticity provides the technology foundations IT organizations need in order to make this transformation—to, in effect, transform into something that looks a lot like a public cloud service: Self-service, automated and elastic. This is the aspiration for most large IT organizations today.
Q: Rich, in a recent report, James Staten at Forrester says, “You’re Not Ready for Internal Cloud.” What do you make of this? Do you agree?
A: I think James is making a good point when he points out that internal clouds require new processes and policies to be effective. Even before the possibility of on-premise clouds, IT organizations first had to standardize and automate infrastructure and processes to the greatest extent possible before they could scale. With the speed and flexibility of cloud computing, however, IT can be overwhelmed by the scale of demand generated by the users it serves. As a result, previously-defined manual or ad hoc approaches can simply break down. Our partnership addresses this concern by providing the foundations enterprise IT require to scale and sustain a private or hybrid cloud through principles of reuse and standardization and deep automation. Thus, in my view, James is offering an appropriate caution and an enumeration of the key challenges faced by enterprises making this journey. The good news is that the technical solutions and process expertise exist today.
Q: Erik, most of us understand the role of automation in this context, but the ideals of reuse and standardization are more abstract. What does this mean to you?
A: A good analog for what we’re talking about is modern manufacturing. Can you imagine a factory working at scale without reuse and centralized control of common components and a standardized approach to assembly and change processes? It would be chaotic. The same is true in an IT context. A key premise of this solution is “industrializing” IT processes: Control over the software supply chain, standardization and reuse of OS, middleware and application components, and policy-driven processes for the construction, provisioning and change of software systems across physical, virtual and cloud environments. The result is the sort of process maturity IT needs to operate efficiently at scale and at the speed of business.
Q: Rodrigo, let’s talk about the front-end of this self-service hybrid cloud. The user experience of this solution has significant implications for adoption and conformance. What do you see as the key principles for making self-service stick?
A: Erik is correct when he says that IT processes must be “industrialized” to take on speed and scale. I’d add another adjective to the vernacular: For IT processes to be delegated via self-service, they must be “consumerized.” Again, public cloud providers offer a perfect example of what this means: A consumer-like e-commerce shopping model for ordering and provisioning IT services. It’s the online store to complement the IT factory. By providing a simple self-service menu of infrastructure and application service offerings, IT becomes a business enabler instead of a bottleneck. By populating these menu options with standardized and approved components, IT retains control of what gets deployed and how these systems are maintained over their lifecycle. And perhaps most importantly, this storefront must provide the policy-based controls for governing how and by whom services are consumed, where they can be deployed and other rules governing their lifecycle. By allowing IT to define and enforce these policies, self-service can be achieved without sacrificing the security and control that IT requires.
To learn more:
watch this two-minute video
Read this white paper
Or visit MomentumSI to learn about this solution offering
What to Expect at VMworld 2010
OK, I admit it: I’m looking forward to VMworld like a kid looks forward to camp. But for exactly the opposite reason: VMworld marks the end of the summer and the beginning of fall tradeshow season. Summer, despite its all-American goodness, is an odd time for our industry—no less busy due to fall preparations, but devoid of the big moves, vision and ideas that make it exciting. That’s saved for the fall, when everyone is back from the beach and ready to listen.
So, if you’re ready to listen, you’re likely to hear the following themes emerging at VMworld 2010:
From cap ex to op ex
VMware practically owns the franchise on the cap ex value proposition, having proven that the hypervisor hath no equal when it comes to reeling in server spending. VMware CEO Paul Maritz has signaled a heavier emphasis on the op ex side of the equation. Why?
I suspect two reasons:
• Virtualization is a cap ex boon and an op ex bust—as compute capacity is made available by the hypervisor, it’s quickly filled in with new machines. The result? An explosion in the number of machines that need to be managed—and an explosion in operating expense.
• The often-forgotten fact that cap ex represents less than 30% of overall IT spending. The larger share of cost savings—higher on the mind of the CIO—is operating expense.
Consequently, op ex is emerging as the new cap ex and will get considerable attention this year.
Renewed emphasis on business value
The cynical among us may tune out when tech vendors flog business value—the hollow and disembodied wah-wah-wah of the adult in Charlie Brown’s midst. But, as an industry, we have a way of dragging the conversation into the weeds and losing sight of what really matters.
Of course, what really matters is delivering value to the business.
It’s encouraging to hear Maritz advocating a truth we’ve advanced for some time: Business value resides in apps, not ops. IT operations enable (or disable) business value that originates in internal, commercial or open source development organizations. Today, the problem is that the typical IT organization stands in the way of this value, slowed to a crawl by manual and bureaucratic processes. This has to change for business value to be unlocked and optimized.
Expect the business value conversation to take center stage—hopefully with more intelligibility than the adults featured in Peanuts cartoons of yore.
Automation
A major part of this change will be next-generation approaches to automation. Today, business lines are forced to wait for weeks, months or longer for applications to be moved into production. And changes to production software are unwelcomed, because a running system—like a sleeping dog—should be left undisturbed. Change wreaks havoc on the data center.
This means slow and costly IT and it’s the impetus behind the strategic automation investment we’re seeing in IT today—new classes of automation far beyond yesterday’s script-based approaches in favor of model-driven “industrialized” approaches to automating IT processes.
Automation and IT management in general will be one of the most important themes this year.
Private and hybrid clouds
The rise of public cloud services like Amazon EC2 and Rackspace have demonstrated a new standard for cost-efficiency and responsiveness that have forced IT to rethink how they measure their own performance. Historically, enterprise IT may have survived—perhaps even thrived—with incremental performance improvements year over year. But no longer: The game has changed and IT organizations are held to a higher standard—a standard set by public clouds.
That’s why IT is all lathered up by the prospects and promise of private and hybrid clouds. As I wrote last week, “I’ve seen the future … and it is self-service private cloud.” It’s a beautiful future.
So, that’s it—what I expect to hear at VMworld 2010. I’m sure other themes will emerge—open source cloud stacks come to mind. What else do you see on the agenda this year?
I’ve Seen the Future … and it is Self-Service Private Cloud
The rise of public cloud services such as Amazon EC2 and Rackspace have paved the way for a fundamental transformation in enterprise IT. This transformation isn’t about a wholesale migration of workloads to the public cloud. It’s a transformation by example, where existing IT organizations are recast to look a lot more like a public cloud service.
What exactly does this mean?
It means self-service—where the interface between IT and lines of business is dramatically simplified and abstracted—from in-the-weeds detail to simple, standardized, ready-to-order services that are presented as a set of menu options within a catalog. Business lines select these services and they’re billed for only what they consume.
It means automation—where the service catalog is populated by a set of centrally managed infrastructure, application and business service offerings that can be deployed on demand across physical, virtual and cloud environments.
It means elasticity—where compute capacity in the data center is provisioned and de-provisioned elastically, in conjunction with dynamic fluctuations in demand.
It sounds a lot like a public cloud service—which is exactly the goal of this transformation. Public cloud has emerged as the new context—the inspiration and the example—for what enterprise IT will soon become.
But unlike the public cloud model, this will enable:
Applications and data behind the firewall—without (real or perceived) concerns about security, privacy or compliance associated with workloads and data running outside of the enterprise.
Workload portability—where IT can dynamically retarget workloads across physical, virtual, public or private clouds to optimize for price, performance or policy.
Scalable cost economies—where IT can capitalize on the cost advantages of long-running workloads running internally. For all its pennies-an-hour goodness, the economies of the public cloud option break down as a workload runs over time.
The solution is a self-service private/hybrid cloud. This is the core of the transformation that should take place to move IT from a bottleneck to a business enabler.
Of course transformations always have a cost.
Forrester VP and principal analyst James Staten is correct when he declares: “You’re Not Ready for Internal Cloud.” He’s correct because this sort of transformation won’t take place simply because we want it to. The cost to the transformation is operational maturity—standardizing and automating infrastructure and processes for speed and scale. But this is a practical caution more than it is a bleak outlook: The tools and practices are available for achieving this level of maturity and creating a scalable and sustainable private/hybrid cloud.
What will happen if IT fails to make this transformation? Demand will follow the path of least resistance as workloads escape to the cloud. Just swipe a credit card. As our friend Rodrigo Flores at newScale says: “16 Digits to Freedom”!
In the end, IT will open for business—and the example set by public cloud services will become the new context for how IT services are delivered. The result? A transformation in cost, agility, and long-awaited harmony between business lines and IT.
Summer Reading for the Well-Rounded IT Professional
Ah, the long, lazy days of summer. Wallowing away endless hours on the beach or in a hammock—complete with hat, boat drink and striking the pose of the leisure class.
You may think: It just doesn’t get any better than this.
Unless, of course, you’re here on Earth with the rest of us, where the lazy pace of summer is little more than a faint memory of idyllic childhoods past.
Just the same, it’s fun to pretend we have free time—and, in doing so, to make the list of the books we may or may not endeavor to read this season.
In that spirit, here is my list—some of my favorite books, better late than never:
BUSINESS
The Innovators Dilemma—Clayton Christensen is one of the truly rare geniuses of management theory. In this now-classic text, he explains why once-reliable advantages turn against us over time. His notion of “creative destruction” is an important model for understanding the organic nature of business.
Crossing the Chasm—Geoffrey Moore wrote this bible for the start-up set nearly two decades ago, but its lessons endure and continue to inform the practices of the entrepreneur. His key message: Focus on and win an initial beachhead.
The Tipping Point—We all love Malcolm Gladwell because he’s smarter than us (me, at least), but remarkably accessible in his writing. He draws us in with stunningly good storytelling. The Tipping Point explains the inner workings of inflection points—when seemingly small and insignificant things cause great big things to happen. Those who are able to apply his lessons are on their way to moving mountains. This is his most important book.
Who Moved my Cheese?—Business would be easy if it wasn’t for the people. We’ve all felt this way from time to time. This simple story is small in size, but it has a big and important lesson: Leaders don’t avoid change—they adapt to it.
TECHNOLOGY
The Structure of Scientific Revolutions—Thomas Kuhn’s treatise popularized the terms “paradigm” and “paradigm shift,” which have since made the list of unoriginal buzzwords we should all actively avoid. But Kuhn’s analysis is anything but unoriginal. It’s safe to say that this midcentury text has informed every subsequent book on innovation theory. It’s a challenging, but very worthwhile read.
Flow—This book by famously unpronounceable Hungarian psychologist Mihaly Csikszentmihalyi popularized the notion of “flow” as a way to describe optimal creative output as measured by sustained periods of focused concentration. The theory of flow characterizes the fully immersed, almost trancelike state we enter when we’re “in the flow.” It should inform the work habits of anyone engaged in a creative pursuit—from software developers to poets.
The Mythical Man Month—Fred Brook’s book of software engineering and project management essays famously debunks the conventional notion of the software development process as following a linear investment curve. Brook’s thesis: Adding resources to a software project that’s already late will only make it later.
The Visible Ops Handbook—”ITIL for the rest of us” is one way to think about The Visible Ops Handbook, which draws from the ITIL framework to offer a set of pragmatic guideposts for achieving high-performance IT operations without heavy bureaucracy and process bloat. Well worth reading for anyone in IT operations.
LITERATURE FOR THE TIME AND ATTENTION STARVED
If you’re like me, you find insight and inspiration in literature outside of the business and technology canons. But you probably don’t have the time or attention span to revisit the classics. Here is some suggested brain-food, fed by the spoonful:
The Poet at the Piano—This unique book by Michiko Kakutani features interviews with famous creative professionals, from visual artists to authors to playwrights. Reads like the best conversations with Charlie Rose.
Best of … Anthologies—Best Short Stories, Creative Nonfiction, Magazine Writing, etc.—these anthologies are a great way to consume a filtered cross-section of literature without becoming a housebound bookworm.
The New Yorker—Skip the front matter and go directly to “The Talk of the Town,” “Shouts and Murmurs” and the featured profiles and essays. Reliably good stuff.
What are your selections?
Are Images the Solution—or Part of the Problem?
Ed Scannell’s recent SearchCIO.com piece on server provisioning is an insightful discussion on the failure of provisioning methods to keep pace in the age of cloud. His explanation of the problem is among the best on the subject, but his proposed solution comes with its own issues.
Quoted in the story, Dan Olds of Gabriel Consulting Group sets up the problem:
“[A lack of sophisticated provisioning tools] is a dirty little secret in the industry. Traditional provisioning done by hand—and even when it is done with scripts—takes too long. People are moving workloads across hundreds of servers at a time into the cloud and then back again. They need provisioning solutions that can be implemented faster and that can scale high enough to address Web 2.0-level problems.”
How software systems are constructed, deployed and maintained is undoubtedly a key chokepoint to large-scale and dynamic compute environments—and the key problem that rPath addresses.
Automation, the story argues, is the only way to counter compounding scale and the need to provision and scale systems on demand—without delay and without conflict. Credit is due for probing deeper and challenging the adequacy of script-based approaches to automation:
“Scripted provisioning is faster than the traditional approach and reduces technical and human costs, but it is not without drawbacks. First, it takes time to write a script that will shift an entire, sometimes complex workload seamlessly to the cloud. Second, scripts must be continually updated to accommodate the constant changes being made to dozens of host and targeted servers.”
IT administrator Jack Henderson agrees:
“Script-based provisioning can be a pretty good solution for smaller companies that have low data volumes, or where speed in moving workloads around is the most important thing. But in a company of our size, the sheer number of machines and workloads we need to bring up quickly makes scripts irrelevant in the cloud age.”
We beat this drum regularly, so it’s nice to see strong agreement on the subject.
Scannell proposes image-based provisioning as an alternative—a simple way to lay down software and to rapidly boot a machine. True enough. But golden images have their own issues:
“The problem … is that the golden image (a bootable image that represents the corporate standard for a particular system type) for one server might not transfer and work exactly the same on any other server, even servers with the identical hardware specifications of the host system.”
What Scannell doesn’t tackle is the fact that focusing on golden images only begs the question: What software goes on that image? How can you be sure it’s the right software? How do you accommodate divergent requirements without allowing the golden image to fracture into many different golden images? How do you keep track of where these images are being used? What has changed? Whether they’re up to date? How do avoid the very real issue of image sprawl?
The answer is a mature operational process for constructing images and keeping them consistent over time. With rPath, this doesn’t start with the image itself—it starts upstream, with the system definition: a blueprint that describes the all of the software, dependencies and policies that go on an image. This blueprint becomes the basis for managing the system over time. When updates and patches must be applied, simply make the change to the blueprint—and synchronize that change with the running system. The change can be made incrementally to a system that’s already deployed or a fresh image can be generated from the blueprint on demand. Easy.
Images themselves can be thrown away after a system is booted. They’re nothing more than a vehicle for rapid deployment. The idea is to create a repeatable process and supply chain instead of managing an inventory of finished goods. It’s idea with deep roots in modern manufacturing practices.
The reality is that managing images is only part of the problem.
The solution? The process for creating and maintaining these images in the first place.
Eight Truths of Enterprise IT
Truth is a funny word. It smacks of empirical fact and righteousness.
But truth is not that. It’s subjective—a cocktail of knowledge, experience, context and bias. I admit that an attempt to generalize “truths” about a topic as broad and complex as IT has the potential to come across as presumptuous … or worse!
But, if you look closely, complexity often betrays patterns. For me, these patterns tell a story that gets—if not to the ultimate kernel—in close proximity to the truth.
So, what are these truths of enterprise IT?
From my perspective, I see eight:
1. Drift happens—complex software systems are rarely consistent or what they ought to be. They drift and morph in definition over time as patches are applied, updates are made and IT personnel tunes, tweaks and fiddles. These changes are typically untracked and IT rarely knows precisely what is running. When they’re initially deployed, systems are opaque. Over time, they’re complete mysteries.
2. Change hurts—IT fears and avoids change because of a Law of Unintended Consequences that hangs over the data center. At the heart of this law is the reality that deployed systems and their dependencies are poorly described and documented. When change happens, stuff breaks. This is why, on the topic of change, IT tends to channel Ross Perot: “If it ain’t broke, don’t fix it.”
3. IT abhors a vacuum—As the cost of computing drops, workload demand increases. This is the force behind VM sprawl and the attendant growth in management costs. Like nature, IT abhors a vacuum. When space is made available, it’s quickly filled in. (Perot may call this “a giant sucking sound”).
4. Demand follows the path of least resistance—Like it or not, enterprise IT competes with a marketplace of alternatives. When alternatives offer comparatively better options in price, performance and availability, workloads will follow the path of least resistance. Public cloud is a perfect example of this phenomenon at work: IT organizations that fail to transform will surely watch in vain as workloads, following the path of least resistance, escape to the cloud.
5. Dependencies grow geometrically—Software is more diverse than ever, comprising an unthinkable array of custom, commercial and open source options. This means that developers have more resources to ply their craft and IT is utterly mired by complex, interdependent and constantly changing systems. It’s made worse by the ongoing abstraction of IT, from managing discrete single-use piece parts to the composition of reusable services. The network of interdependency is massive and—much of the time—poorly understood.
6. So does scale—Each subsequent architectural advancement leads to an increase in scale. Scale exploded as mainframe gave way to client-server and client-server gave way to web. Today, we’re seeing x86 architectures, virtualization and cloud are all driving growth in the volume of systems that need to be managed.
7. Proportionally, budgets will always contract—Operating budgets cannot keep pace with growth in IT scale, so even when the top-line budget is growing, the budget per managed system is always contracting. IT will always be forced to do more with less—forced to find new ways to change the economics of scale.
8. Complexity is the mother of reinvention—When IT complexity reaches the frontier of existing tools and processes, IT must reinvent. Containing complexity is like holding back a tide. The only way forward is through reinvention, embracing new tools and approaches for dealing with IT complexity at scale.
So that’s it—eight IT truths as I see them. What truths do you see?
Is DevOps Subversive?
If you follow DevOps, you’re probably familiar with the sentiment that this burgeoning movement could have mildly subversive motives.
As a solution to the dev/ops bottleneck, one advocate recently proposed:
“Hire wicked smart people and give them all access to root.”
While this may be a rally cry for radicals and revolutionaries, it does tend to trivialize roles and processes in IT and probably doesn’t engender trust with the mainstream—nor does it correct the perception that DevOps may breed a cowboy culture.
To be clear, I don’t at all believe that DevOps is meant to be subversive—in fact, I believe deeply in the premise of DevOps and see it as a necessary evolution for IT. But I can certainly see how some are led to fear what it stands for.
To some, DevOps seems to minimize principles of governance, repeatability, separation of duties and other good practices of mature IT organizations. To these folks, DevOps seems like the oil to ITIL’s water.
I came across a post by John Vincent that does a masterful job of describing why DevOps—for all its goodness—collides headlong with certain enterprise realities.
Advocates for DevOps often unwittingly fuel the perception that this worthy movement is one giant end run around traditional IT operations. While I’m certain this is not the intent, we’re all familiar with the maxim that perception is reality.
Like many anti-establishment movements:
DevOps is super-smart—DevOps focuses on the contributions of the most gifted few to make IT run—the script wranglers, the mavericks and artisans. It often minimizes the fact that genius is neither scalable nor repeatable.
DevOps is provocative—DevOps advocacy sometimes pokes its collective finger in the eye of the IT establishment, galvanizing the support of the few who “get it,” but perhaps alienating those who don’t—those who represent the IT majority.
Of course, smart and provocative are not bad things—in fact, they’re essential to any movement for change (can you imagine the American Revolution led by passive everymen without conviction and a strong point of view?).
The secret is using smart and provocative as a bridge instead of a wedge.
Today, DevOps is gaining traction in the world of web ops, but hasn’t found its home in traditional enterprise IT. At the risk of some heckling, I’ll go out on a limb and suggest that, for some DevOps advocates, this fact is worn as a badge of honor: Mainstream attention means that DevOps has jumped the shark.
The principles of DevOps are undoubtedly right on: Compounding scale, accelerating change and contracting budgets are forcing IT to the brink. At the same time, public cloud is emerging as a model for the future of IT: self-service, automated and elastic. The universally accepted truth is that IT is under pressure to change. Is DevOps at the heart of this change? I certainly hope so.
But the question remains: Will the revolution take hold or will it become a footnote in history—a fringe movement that fails to connect with the mainstream?
In my view, the future of DevOps depends upon cooperation with mainstream IT—perhaps DevOps thought leaders collaborating with (gasp!) ITIL thought leaders.
Maybe there’s a way to turn oil and water into peanut butter and chocolate?
I think it’s worth exploring. What do you think?
Disintermediation of IT: Lessons from “Bubble 1.0″
**Register now for a related webinar on 6/24: “Focus on IT Agility”**
Back in the silly season of the late 1990s, all measures of reasonability were suspended in favor of a punch-drunk land grab for “eyeballs” on the path to IPO. While e-commerce was absurdly hyped, it was also an important new context for selling stuff that was bound to disrupt the established value chain.
E-commerce promised to take the friction out of the value chain—a more efficient way to connect supply with demand. To call a retailer “bricks and mortar” was the highest form of degradation; these out-of-touch progenitors of modern business were doomed to become footnotes in the annals of commercial history.
But no participants in the value chain were more maligned than the wholesaler or distributor. These folks made money by aggregating and matching supply and demand. But in the age of online commerce, was this role necessary? Many thought it wasn’t—and from this premise, their obituaries were written.
The fancy word for this was “disintermediation”—a fundamental shift in the value chain that rendered a set of participants irrelevant. It’s a concept that got a whole lot of ink in now-defunct and previously high-flying “new economy” publications.
Fast forward to 2010, and the same sort of dynamic is at work again.
Cloud computing—specifically, swipe-a-credit-card forms of public cloud—promises to disintermediate enterprise IT. As the story goes, in the face of long delays, business lines and developer groups will follow the path of least resistance, deploying their workloads to the public cloud. Applications will go rogue and traditional IT will become irrelevant—disintermediated by the cloud.
Do I believe it? Yes and no.
Bubble 1.0 did not change everything—but it did force everyone to change.
Participants in the value chain willing to rethink their roles and value propositions capitalized on the shift. Those who dug in their heels and shook their fists in angry protest? They’re featured in the footnotes.
There is a sober lesson for IT buried in the drunken silliness of Bubble 1.0: Don’t fight the forces of change. Some degree of skepticism is certainly healthy, but look at these punctuated shifts as new opportunity—the natural course of evolution.
That’s exactly what we’ll cover on Thursday, June 24th in a webinar discussion bringing together CTOs of newScale, rPath and Eucalyptus Systems to envision the future of IT in the age of cloud computing. Be sure to register to participate!
The premise of the discussion: IT must transform into something that looks a lot more like a public cloud. At the heart of this transformation is a new tool chain that allows IT to change the economics of IT service delivery and to remove the friction from the IT value chain. IT becomes a self-service provider of on-demand business, infrastructure and compute services.
So, will cloud computing change everything for IT? Probably not—but it will force everyone to change. Those who don’t change? We all know how that story ends.
The Invisible Thread of Innovation
IBM Rational’s user conference, “Innovate 2010,” kicks off today with a bold and inspiring message about the importance of software development: “Software is the invisible thread of innovation.” It’s no doubt correct; software has become absolutely vital—in many cases, core—to the execution of business. For a new generation of web-oriented companies, software is nothing short of the business itself.
If you ask me, this is a message development organizations should embrace with the pride of a job well done—and IT operations should embrace as a catalyst for change.
Why? Because, today, there’s an impedance mismatch between dev and ops. Dev churns out new software and changes far more quickly than IT can respond. Dev produces this invisible thread of innovation, which IT struggles to consume.
IT often lacks the tools, process and culture to match the complexity, scale and change of software in production. This is the argument behind the DevOps movement, which has done a great job of shining light on the dark space between dev and ops.
It’s also an argument for the software distribution hub, which is about drawing the invisible thread of innovation from the source of software—custom, commercial and open source; to deployed business services—across physical, virtual and cloud. When changes are made to the software sources, it’s seamlessly flowed through the hub and to deployed systems and business services.
In this manner, this approach is about managing the entire software supply chain as an integrated thread—from the origin of the software to the business service in production.
The message? Software is undoubtedly the invisible thread of innovation, but innovation isn’t realized in dev—it’s realized in ops. This is why this thread must become less of a conceptual whiteboard ideal and more of an IT supply chain reality.
Envisioning A Software Distribution Hub
Modern manufacturing is a direct consequence of a forced transformation—a transformation resulting from changing economics and massive product and supply chain complexity.
The same sort of transformation is taking place today in enterprise IT—forced by similar challenges and following a very similar arc.
Manufacturing has evolved from manual to automated, ad hoc to repeatable. From art to science. Manufacturing has been forced to “industrialize.” Aiding in the effort are product lifecycle and supply chain management tools for streamlining manufacturing process and linking together previously isolated stages in the value chain.
Several factors drive manufacturing complexity:
Many inputs—raw materials and product sub-assemblies are sourced through direct and indirect means. Inputs must be made available for production runs.
Many actors—each phase of the manufacturing process involves many different roles and individuals who must work in harmony to produce the end product.
Massive scale—the volume of units shipped and diversity of product lines drives massive scale in the volume of raw materials, work in process and finished goods.
Constant change—changes in the specification and availability of inputs must be communicated and propagated downstream, while changes in demand are communicated and propagated upstream.
Frequent specialization—end products must be tweaked, tailored and localized to satisfy diverse market requirements.
Manufacturing is a useful analogy for the transformation taking place in enterprise IT. After all, these same challenges—many inputs, many actors, massive scale, constant change and frequent specialization—could just as easily describe the state of IT today.
Manufacturers have addressed complexity by creating a centralized infrastructure for controlled reuse of standardized components, collaboration between roles, and automation of key processes. They have created, in effect, a “hub” that automates and streamlines how inputs become outputs in a way that is efficient and scalable and based on principles of standardization and reuse.
They have integrated these standardized components all the way back through the supply chain.
IT has no such hub today, relying instead on independent, often duplicative efforts and disconnected, fragmented processes to construct and maintain a system.
For IT today, scale and change are compounding at the same time budgets contract and business line expectations increase. IT is undergoing a forced transformation—from art to science—much like manufacturing organizations of the past.
The transformation for enterprise IT should follow a similar path, where a centralized hub becomes the control infrastructure for managing IT system construction and change. This hub becomes the basis for managing and reusing standardized system components—components that are integrated back through the software supply chain.
You may think of this like a Rubik’s Cube, where the colored blocks represent reusable software components which—when combined—represent a new system.
These components are managed centrally and reused liberally to construct new systems. All the components and the systems themselves are deeply modeled and version controlled, ensuring that they’re well defined and controlled throughout their lifecycle. When updates are made to the components, change is flowed through the hub and cascaded en masse to hundreds or thousands of deployed systems.
With a software distribution hub, key challenges for IT become surmountable:
Many inputs—system software components are standardized and versioned, giving IT control over what software is put into production. The software supply chain is fully integrated—from the deployed business services all the way back to the original sources of the enabling software—custom, commercial and open source. Changes to software and configurations flow seamlessly from the sources to the consuming systems.
Many actors— rather than duplicating efforts, working at cross-purposes and creating conflicts in production environments, all contributors to the IT value chain are in perfect coordination. Standardized components are reused, not recreated. Where they’re reused is tracked. Changes to these components—in dev, test or production; by OS, middleware or application teams; or by third party software providers—is seamlessly propagated from their source, through the hub, and into production.
Massive scale—traditionally, adding systems meant adding people. With the software distribution hub, scale can grow at near zero marginal cost. Reuse of system components means massive leverage on the management of software in production.
Constant change—with change flowing through the hub, introducing change at any layer of the stack is simple, free of conflict and reversible. Changes to custom, commercial or open source software—or to configurations or business service definitions—seamlessly flow from their source to their destination.
Frequent specialization—one-size-fits-all gives way to customized systems, as standardized components are mixed and matched to address diverse business requirements. Because these components are controlled and managed centrally, there’s no added management overhead for this sort of system diversity.
Legacy manufacturing processes were forced to transform under the weight of complexity, scale and changing economic conditions. The same transformation—by the same forces—is underway for enterprise IT.
Today’s approaches are too slow, costly and chaotic to address modern system complexity and IT budgets. The only viable solution is a new approach—a distribution hub, with deep integration from the business service back through the software supply chain—that takes the cost and complexity out of managing IT environments in an age of massive scale, accelerating change, and elusive op ex budgets.
