I decided this should be the primary focus of my writings, or at least the filter through which I discuss the technical and architectural aspects of what I do – which is consult with enterprises of all sizes regarding their IT architecture. There are so many blogs written by folks in my space that will give amazing insight into specific technical features and “how-to”s, and I’m sure I’ll throw a few of these in here and there. What I do find lacking a bit is the WHY, and also WHY IT MATTERS.
First, some definitions are in order.
What do I mean by the word “tactical”? When I refer to an organization as behaving tactically in regards to IT architecture, that means that they are solving problems and tackling projects as they are presented to them. Each problem/project has its own set of demands and requirements, and for a variety of reasons, the organization is set up to deal with these in an isolated way- perhaps budgets are allocated by project, the political structure is such that people protect their fiefdoms jealously, or it’s just easier and faster to deal with in this fashion. For whatever reason, each issue that comes up is handled as distinct. This leads to data silos, multiplied administrative and training requirements, and more than the minimum number of data copies (which presents real risk).
The “Strategic” organization, in contrast, will take a step back and see that most IT problems and projects have much, if not everything, in common. These firms are most concerned with creating and maintaining a responsive, reliable, measurable, and operational IT ecosystem in which efficiencies are realized, and that can provide management with the confidence that future projects (such as acquisitions or new go-to-market initiatives) can be handled with relative ease. I’m proud to work with more than a few of these companies, and they are truly enjoying the benefits of this approach.
In my role as a technical evangelist, I find that most often I am evangelizing this latter approach to clients more than I speak about specific technologies. The technologies I choose to offer clients, and I am lucky enough to have the freedom to choose any technologies I wish, all provide my clients with the tools they need to go down the Strategic Path. Of course, my clients can continue to use these tools tactically, which while functional, misses the point. Technology alone can’t transform an organization; it takes patience and discipline from the top down, and usually a few iterations to get it right. The wrong technologies, however, can BLOCK the Strategic Path, and it’s important to recognize this up front because in the IT industry, you’re typically stuck with your tools for a minimum of three years.
So I’ll conclude this first chapter with this- I’ll make no secret that the core set of products I have recommended to my clients includes NetApp, Commvault, and Riverbed. There are a few others I add to that mix when appropriate, and other sets of technology I steer clear away from as they tend to block the strategic path. I’ll try to justify those decisions as well, from a strategic perspective.