Adventures with Windows XP
A few weeks ago I had a problem where I required access to a Windows XP machine in order to track down a bug in a PowerPoint file that was crashing on my Mac. Luckily, such access is easily to accommodate nowadays thanks to the wonders of VMware View and our IT department’s ability to rapidly enable access to desktop VMs when they are needed.
So, with View access at hand, I set out to launch a pristine XP virtual machine and proceed to remove the offending OLE object that Office 2008 for Mac couldn’t seem to digest. Upon launching the VM, I was greeted with a site I hadn’t seen in quite some time…
Aah, the clear blue skies and green fields of Windows XP. What promise it offered us when it was released! Along with the satisfying startup sound (which I’m way too blog-challenged to include in this post), it heralded a new day in desktop computing. For the first time, Microsoft was opting for a default background that was free of Windows logos and offered up a natural scene photographed in bright, refreshing colors. A fresh new OS which heralded a new era of Windows (never mind the travesties that followed with Vista, etc.).
As I lost myself in the peaceful wonders of this freshly provisioned XP virtual machine, I started thinking about the stark contrast today’s IT reality presents when compared to this beautiful, pristine, peaceful scene. In fact, trying to find a way to describe the juggernaut of technologies, process, hardware, and people found in even the best managed IT environments led me to the conclusion that, far from representing peaceful green fields and blue skies, IT is a lot more like the popular (if consummately odd) Konami videogame Katamari Damacy. In this game, you play a prince who for reasons far too ridiculous to explain in this blog is tasked with rolling a ball over a landscape of objects that end up attaching to it and making the ball bigger and bigger. You start by rolling over small objects and over time you end up building a ball capable of rolling over skyscrapers and even planets. The object of the game is to build a ball big enough to satisfy the irrational and often hilarious demands of your crazy king.
Rather ridiculous, but in my view all too appropriate!
I was surprised at how this game so accurately captures the harsh reality of IT which has to both move forward while continuously dealing with the ramifications of technology choices of the past. How can you make real progress while carrying around decades of technology baggage?
With this in mind, I asked myself what kind of IT choices would we make if we had the opportunity to start with a clean slate. Specifically:
If I could start from scratch and build an agile, modern IT environment that can scale and meet business requirements of a mid to large size enterprise, what would I wind up building?
As I thought more about the idea, I decided to give this concept the name “Greenfield Enterprise” and set out to try and document how it could all come together. My hope is that by taking this fictional clean slate approach it might help us see through the “[fog of war|http://en.wikipedia.org/wiki/Fog_of_war]” that often clouds IT decision making and help us make better choices for the future. Now, it’s fair to say that decisions of this scale around something as important to a business as it’s IT environment are far more than can be summarized on any blog (even in a post as long as this one). Each business is different and approaches IT with a different perspective. At the same time, I have a strong sense that the freedom to look at IT with a blank slate might inspire some imagination around solving common business problems and uncover limitations in even the most modern of approaches to IT.
The topic seemed big enough to warrant splitting into a few separate posts so as to better organize the argument (as well as give me a reason to continue blogging more frequently!).
In this first part, the goal is to lay out a simple categorization of technology decisions that our Greenfield IT department needs to make as well as explain a bit about the philosophy that our fictitious enterprise will use to make those decisions. This is important because absent a coherent point of view on the role of IT and the biases people will bring to the decision-making process, we’ll just wind up with another Katamari-like ball of gear, apps, and problems. It’s worth pointing out that neither the decision taxonomy nor the philosophy I outline here is expected to be exhaustive nor 100% accurate in all cases. Technology choices are only part of running a proper enterprise IT environment — people and process are a huge part of how things work or don’t.
For the purposes of this exercise we’ll stick to technology matters since those are easier to apply to a broader problem set. These observations will be based on what I’ve seen work and not work in environments ranging from large enterprises and big web companies to small startups. My hope is that they will encourage discussion across a wider range of people whose experiences could very well be different than mine. I also want to emphasize that the question I seek to answer is not simply “what would I do with IT if I was starting a new company?”. While I’m sure that some of the conclusions we’ll get to as part of the Greenfield Enterprise exercise will apply to startups, the challenge is to figure out how to construct an IT environment that can meet the scale demands of a company with demands larger than those of a company of less than 1000 people.
Ok, let’s get started.
What kinds of technology decisions will we be making?
In order to facilitate the process of making good decisions for our Greenfield Enterprise, it’s worth laying out the various categories of technology choices we’ll need to make. In order to keep things simple and organized, we’ll start with these four:
Within each of these categories there’s a whole range of detail which we’ll cover as we outline the choices that we’ll make for our Greenfield environment. The details, of course, are important. However, given the scale of the challenge ahead of us, organizing things into these four buckets will help us not only make better decisions, but ultimately organize the projects that will implement them a bit better.
The Greenfield IT Core Principles
Before we can start making choices, it’s important to outline the point of view, opinions, and biases we’re using to make them. Even in a Greenfield Enterprise, technology professionals bring experience, points of view, and biases which will ultimately influence their choices. Additionally, every business has a different view of IT and its overall importance helping the business drive better results. Hopefully, having a coherent philosophy about the role of IT and how decisions should be made will help the resulting IT environment and the folks that manage it work better.
Let’s start by outlining the core principles of Greenfield IT (in no particular order):
Modern – We will make IT choices built on proven, but modern technologies and techniques. Since we’re starting from scratch, why would we burden ourselves with old stuff!
Simple – We will fight complexity at every layer of our environment. From infrastructure, to applications, to processes if it’s difficult for us to explain to the business, it’s likely too complicated.
Agile – We embrace the fact that the business is always evolving and expect to build an environment where the evolution of the business is not held back by its IT choices.
Secure – We will not compromise the security of our infrastructure, data, IP, or processes. We expect any IT choice we make to not make tradeoffs on security in exchange for any other benefit.
Performant – We expect to build an IT environment which helps enable faster execution of our business. The speed of our business should be enhanced by the performance of IT.
Cost effective – IT is a critical enabler to our business, but it is not our core business. We expect to be able to measure the cost of all aspects of our IT decisions against the value it delivers to our business. The best way to measure cost in Greenfield IT is on per-user basis.
With those core principles spelled out, let’s take a shot at describing how we want to make decisions across the four categories described earlier.
Just Enough Infrastructure
Greenfield Enterprises should have only as much IT infrastructure as is required at any given point in time. In keeping with our principles of agility, simplicity, and cost effectiveness, we should design an environment where the amount of physical equipment owned and operated directly by IT is kept to an absolute minimum. At the same time, we want to make sure that capacity (whether compute, storage, or network) is available to those who need it, when they need it. This capacity needs to be easily metered in order to quickly allow us to allocate and de-allocate it across our business over time.
Our network infrastructure should follow the same principles we established for compute capacity. It needs to be simple to manage, and highly agile. Because we are very likely to consume technology and services provided by others, we need to be able to model and manage a network that spans geographical and business boundaries. Similar to compute, network capacity should be available, and metered on-demand. The ability to de-allocate or reconfigure network resources, without making physical changes is also essential.
Our Greenfield environment requires storage services that are secure, scaleable, reliable, and broadly accessible. Regardless of our choice of storage architecture, its crucial that our data be managed consistently. It is also very important to be able to determine with reasonable accuracy the location of all our data so we can remain in compliance with the way our business operates. In order to accomplish this, we expect to consume storage as an easily accessible service that allows for multiple ways of integration. Our storage service should also be exposed in terms that make its physical deployment architecture invisible.
Applications don’t make us more competitive, our execution does
Applications provide a strategic advantage for us by enabling simpler business processes, not by providing for infinite customization. We recognize that choosing applications that are accessible for our users across devices and environments makes them, and ultimately our business, more productive. For applications that support core business activities such as finance, customer management, HR, etc. we will happily trade flexibility and customization in favor of productivity and end-user satisfaction. Our success does not come from the fact that we have the most customized, sophisticated HR system in the world, it’s because we can on-board employees quickly and the hiring managers who use the application feel productive and happy.
We will look to custom development as an option for any application whose requirements can’t be satisfied by any kind of packaged application. Our custom applications should be developed on an open platform environment that enables our developers to build and deploy applications quickly. We expect that platform to provide services our applications consume rather than act as a collection of various types of middleware which we then have to independently manage. The platform environment we choose should enable us to deploy and scale these applications transparently and across both our minimal internal infrastructure as well as that which we source from other providers.
In order to support the creation of applications by a broader skill set of professionals, we expect to provide a development environment suitable to non-programmers that allows them to easily assemble applications and deploy them on our platform. We will avoid building custom apps that have architectural dependencies that limit our choice of deployment environment and vendor, regardless of the productivity benefit they offer. Just because we choose not to run a complex, custom middleware environment doesn’t mean we are ok with getting locked into a platform that hides it. Custom applications should leverage open source frameworks and tooling to avoid reinventing the wheel.
Regardless of the mix of applications we ultimately purchase or build, integration and data access are two critical requirements. Our choice of best of breed packaged and custom applications will create a need for various levels of integration to minimize duplication of data and keep our business processes streamlined and simple. We will require integration technologies that allow us to connect applications and data together, while simultaneously enabling visibility of the activities that are taking place across our infrastructure. Each application will also need to ensure that we own all our data and have ready access to it through multiple means. Data access is critical to both better integration as well as avoiding lock-in to any particular app or vendor.
Services that help us communicate and collaborate more effectively and are always available
Traditional IT departments look at these services starting from the perspective of the specific technology packages (Exchange, etc.) that fulfill them. This often leads to poor integration, poor service quality, high cost, and unhappy users. Instead, we make an explicit choice to describe our requirements in terms of services and capabilities and expect to partner with a third party that can deliver and manage them similarly.
Communication services are a crucial ingredient in our productivity. However (much like applications) managing email, calendaring, and other communication services are not really a core competency of Greenfield Enterprises. These types of services must enable user and groups to have faster, richer interactions both within our company as well as outside of it. We need to support multiple type of content (voice, text, video) and need to be accessible across a wide range of devices both inside and outside our network. It is crucial that these services are managed from a single, end-user perspective and work as an integrated unit, even as they span devices and content types. Doing so allows us to easily allow additional services in the future as well as prevent costly overallocation of resources.
Scheduling is also a critical complement to making us more efficient. We need to enable easy coordination between individuals, across groups, and including resources like conference rooms, bridge lines, etc. The mobile, distributed workforce we have today requires an approach to scheduling that accounts for the location of a participant and support whatever medium (voice, video, mobile) that is most appropriate for them. The scheduling service could also provide users an easy, intuitive way to help them understand how they are managing their time. By enabling this type of visibility, we give our users more information they can use to improve their productivity and be more effective at their jobs.
Since most of the work done at Greenfield is done across teams of people, providing services that enable collaboration across users is critical. Easy to adopt document and project management solutions will make a big impact in the productivity and communication of our workforce. Beyond simply exchanging email attachments, we need to provide for exchanging of rapidly evolving wide range of documents across groups of people. These exchanges should provide for transparent versioning, easy security, and be readily accessible across a wide range of devices and applications. In addition to document sharing, the collaboration services need to provide ways for individuals and teams to create, share, and manage projects and the tasks that comprise them.
Security built around users, data, and services
Security in IT is often designed and deployed along the various layers of infrastructure and apps available. This approach, along with the fact that security is a moving target makes it much more difficult to properly deliver a strategy that effectively covers all the various surface areas involved in IT. A poorly implemented security strategy can be a significant obstacle to the productivity and agility we envision in our Greenfield environment.
Rather than starting the design of our security models from the infrastructure up, we choose to look at things starting from three key perspectives and working down from there:
Users – Centralized access to key infrastructure, applications, and services on a per user, per device basis. Provisioning and de-provisioning models that make it easy to grant and revoke access across the environment as well as report who has access to what.
Data – There’s a wide variety of data across our business. Whether its data from an application or a document built by a team of users, it is critical that all of this data be stored with consistent security models. The storage services that power our infrastructure should implement security in a way that leverages our intent to manage access from a user-centric perspective.
Services – In addition to users and data, it is important for our security model to consider the integrity of any business process that is serviced by our infrastructure. Access to services is managed from a user perspective, but it is critical to complement that with a security mechanism that validates that any given service is operating correctly and has not been compromised by any external element.
These three key dimensions of security will help us describe how we would design and asses the security of our environment. That said, we will also count on the ‘cumulative effect’ of selecting enabling technologies for our environment that are themselves secure. Given the likely mixture of technologies we operate ourselves and others we consume from providers, we will need to ensure that security is applied consistently regardless of who is delivering the service or where it is being delivered from.
Simpler, smarter management tooling
Complex management tooling is a side effect of complex architectures, so we expect our infrastructure’s bias towards simplicity and consistency to be reflected in a dramatically limited need for elaborate management tools. In order to enforce consistency in how we manage our environment, we will require management solutions that help us look at our environment from the following 3 criteria:
Performance – Is this technology or service meeting its service level?
Cost – What is the per-user cost of this service?
Risk – Is this service operating within our security guidelines?
Whatever management technologies we do procure should enable self-service, metering, and automation while not sacrificing uniform levels of access and visibility across the infrastructure. These technologies should also be built and delivered in such a way that they support environments where part of the infrastructure and applications may be delivered by an external provider. We will avoid duplication of management technologies by choosing providers who can make service level commitments that are easy to validate and limit our need for ‘defensive’ management technology.
Next up… Part 2: The Case for Cloud & SaaS
The goal of this first post was to introduce the concept of the Greenfield Enterprise IT environment, propose some categories for the various decisions we’d need to make, and attempt to describe a point of view that will influence how we would like to make those decisions. The next post will attempt to outline the choices and decisions we would make if we were to look to cloud computing and SaaS exclusively. No solution will be considered unless it is deployed in a cloud environment or delivered as a service. My hope is that taking an ‘all-in’ approach to the cloud (with repeated, half-hearted apologies to Microsoft!), will reveal there are still plenty of gaps left unfilled in attempting to deploy an entire enterprise IT environment using Cloud & SaaS.
In the meantime, I welcome your thoughts on what we’ve laid out here. I’m eager to hear your comments on the concept of “Greenfield IT” as well as any observations on the categories or IT philosophy I’ve outlined here. As I mentioned at the beginning of the post, this is all based on my opinion and experience. It would be great to extend this with your feedback and insights.
’till next time…