I’ve been focused on blogging over at EMC’s InFocus blog for the last year, but I want to get back to the Practical Polymath and start blogging more frequently about a wider variety of topics. First up is some thoughts on a topic I’ve been spending a lot of time thinking about these days: Bespoke IT versus Fit for Purpose. We’ve spent a lot of time on bespoke IT in the industry, building new applications, silos, architectures, etc. to meet a specific need based on the skills and tools we are familiar with. We often don’t have the luxury to go out and investigate what the right tools would be and learn them in order to best apply them. If I think of this in sartorial terms, we make some outstanding, finely fit suits, but it might be in last decade’s style or colors. The suit might be of the highest quality and yet might not meet the needs of the wearer, or might stand out for all the wrong reasons in a crowd. Just because it’s bespoke doesn’t mean it’s the best way to approach the problem.
This is a long lead in to what I really want to talk about, the idea of Fit for Purpose. EMC acquired Adaptivity and I’ve been lucky enough to get to work with that great team, and learn a lot about how they think about IT, Applications and Infrastructure. They have a lot of talent on that team and I’ve learned a lot in conversations and brainstorming with them. Their Chief Scientist is Sheppard Narkier and he’s started to share many of his ideas, thoughts, and experiences on InFocus, see his post on Lessons Learned: The Quality of Design is not Fuzzy. On the surface , “Fit for Purpose” is nearly self explanatory, the idea of designing IT and Business systems based upon what they’ll be used for and how they’ll consume infrastructure. But to those not used to thinking in that paradigm, this explanation could be considered too coarse grained as a definition, let me explain a bit further.
When I first started working with Adaptivity as a partner, I latched upon the idea of Fit for Purpose because it allowed me to express in words something that was lurking in the back of my brain for a while. So much of what I was doing in IT felt reactive, we were analyzing systems after the fact and trying to optimize them. This seemed inefficient and backwards. That seemed like my lot in life as an infrastructure guy, we run what the app guys give us. The DevOps framework was changing a lot of that, pulling infrastructure and operations teams further forward into the design lifecycle process. The goal was to make systems run more efficiently. We were headed in the right direction, but there was some context missing. So here I am, thinking about DevOps and reveling in the improvements it could bring when I happen upon Adaptivity and their Fit for Purpose concept. When I initially learned about it I only thought about it in terms of how it was implemented in their product Blueprint4Cloud as they were able to inventory and analyze a customer’s application portfolio and identify patterns of infrastructure consumption (i.e. memory, CPU, disk and network). They could identify those blueprints that should be implemented in private or public clouds to address the needs of each application’s behavior within the portfolio. Their research had identified over 30 common application patterns of infrastructure consumption that most applications, custom dev or COTS, could be aligned to. This was great, taking analytics and applying it to application portfolios, a big step forward in my opinion, but I wasn’t seeing the full picture yet.
Portfolio analysis is still reactive, looking at what we’ve done in the past and identifying ways to simplify the environment. Further work with the team and conversations with Sheppard and some of the other big brains helped me learn even more about their concept of Fit for Purpose. I’m a big fan of iterative elucidation, but it requires cycles, something I’ve not had a lot of the last year. Recently I’ve gotten to have some in depth conversations on this topic again, the best way to learn.
Fit for Purpose isn’t just about looking backwards, it’s a design concept that we should use the moment we begin planning a new IT for Business system (I’m just going to introduce that phrase in this post and come back to it in some other). This is a process that start ups have the luxury to use from the inception of their team, but most IT shops have a lot of legacy processes and skills and tools that make adopting such a strategy more difficult to do. Many people have refined this idea over the years, but my eyes have recently been opened and I want to share some of these thoughts, so many of you might be saying “well ,duh!” but indulge me a little. The Fit for Purpose idea as I’ve been thinking about it is that at the outset of system architecture we think about why we are building it, what we will be using it for and allow that to guide our decisions. On the IT Service Management side of the house we always talk about the process defining the tool and not the other way around. Often I feel like we are letting the tools in our toolbox define the way we approach the building of a system, a hammer looking for a nail.
An example: imagine you were building a tool to replace a homegrown application that was a little long in the tooth and undersized. This tool is very concerned with the relationships between systems and how to group them. The purpose of the tool is decision support; helping people make better decisions about how to execute a certain type of project we deliver frequently. But the current tool is more of a repository for data that then has a lot of reports run against it and requires a lot of manual effort by the team to turn those reports into executable plans. What if we made a decision about the back end relational database for the replacement application based on what was supported by the cloud platform we were thinking of building it on, rather than the purpose of the tool? We would have to do a lot of work to create functionality focused on learning about the relationships between systems that might’ve already been developed in another platform. If we made the decision based on the purpose of the tool and the type of data we would be working with we would choose a graph database, which excels at working with connected data and relationships. It takes a lot of effort to make a non-graph database act like a graph database.
Maybe the way to approach this is to have a matrix of known problems and solutions and apply those in the initiation phase of a new system development project. If the data is highly connected and focused on relationships and the system’s focus is on enabling better decision making for field deployed employees we should use a cloud enabled, graph powered pattern. The key to that design discussion is to leverage the use cases that the system must satisfy as the driving force for this kind of decision making. Cloud deployment is not the driving force for functionality; it is a tactic to solve the problem of enabling a large population of mobile users to share data effortlessly while enabling significant scaling to occur while obeying a linear cost scale. Fit for Purpose allows the designers to separate design concerns which is a fundamental tenant of sustainable architecture design.
Maybe it’s too zen of a concept, but we have to accept that for many of the things we are building in IT there are solved problems that we should take advantage of rather than defaulting to the bespoke route with the tools and skills at our fingertips.
Implementing this process isn’t easy by any means, it requires an approach like hybrid cloud for workloads, but applied to development: where is the best place to develop this system based on the functionality, compliance, security, and cost attributes associated with it?