“Too many tools!” That’s how IT managers feel. The systems needed just to run IT can cost millions to acquire and operate. Yet without appropriate tools, how can you run a service desk, IT operations center, or a project management office?
Undoubtedly, it’s critical that your IT management tools approach be well thought out. You can’t afford redundancy or miscommunication amongst your tools. And yet, there are so many choices in an evolving landscape. Do I need a CMDB? What about a common event console? Discovery tools? Where does application lifecycle management fit in? How do project and service portfolio management interact? Where are the vendors overlapping? How do these tools need to talk to each other? What data do they share? And most importantly, do we understand the processes they are intended to support?
I use enterprise architecture techniques to develop an understanding of an IT management system and how it needs to evolve. These techniques are based on four different “views,” or perspectives:
- The Process perspective
- The Functional perspective
- The Information perspective
- The System perspective
Processes (aka value chains or value streams) are the end-to-end pipelines – crossing functions – that deliver some value for stakeholders. The classic example is the order to cash lifecycle in manufacturing. Value streams are activities, heavy on verbs, countable and measurable. They should be few in number and are supported by functions. They can be decomposed into workflows, activities, tasks, and so forth, but should always remain countable. If you don’t know when a given activity is “done,” it doesn’t belong in the process area.
Functions (aka capabilities, business services) are ongoing organizational components. “Hire Employee” is a process, while “Human Resource Management” is a function or capability. The steady-state collection of interacting functions or capabilities can be viewed as a value network. Functions can be decomposed into smaller functions.
IT systems support the application and infrastructure services we all know and love. Oracle Financials, Salesforce.com, BMC Remedy, and so on – whether supporting a business function like the CFO’s office, or an IT function like the Service Desk – the concept is the same. Like functions, systems can be decomposed into subsystems.
Finally, data is the subject and object of the processing. The information concepts, like Customer or Server are the endless inputs and outputs of the processes and capabilities, supported by the IT systems. Like the rest, data can be decomposed from high level subject areas (e.g. “Project Management Data”) through entities (e.g. “Customer”) all the way down to granular data elements (e.g. “Serial Number”).
In summary, Processes cross and are managed by Functions, which in turn, rely on IT Services, and Data in its various forms ties them together.
How does this framework help in the real world? Let me work an example.
Let’s suppose you are considering acquiring an Application Lifecycle Management (ALM) tool and are wondering how it might fit together with your existing investments. The tool you’re looking at does certain things very well, but you know that it overlaps with your project management tool in particular. You also have an existing investment in a requirements management tool, and you are sure that it will need to integrate with some “downstream” systems.
You might start with a simple flow:
- Propose project
- Fund project
- Develop application
- Build & deploy application
- Operate and maintain application
- Enhance application
Right away, you might notice that this set of activities is not truly sequential. A typical scenario in your organization is that there is a 6 to 18 month project to “stand up” the application, but after that, the application team won’t be funded via a project; some developers move on and some remain as part of an ongoing service. They will enhance the application, constrained by their capacity. They will continue to deliver releases based on requirements, require source code and build management, and so on. Operating and enhancing the application occur simultaneously. Developing the typical application increasingly uses Agile techniques, so as a project they look different from older “waterfall” approaches. However, we don’t have to have a strictly sequential flow to use those activities in an architectural view.
Let’s go back and list more systematically the systems you need to consider in making the decision whether or not to purchase an ALM tool. Those pre-existing systems are:
- Project Management System
- Requirements Management System
- Software Configuration Management System
- Defect/Issue Management System
And an IT Service Management system, with the following modules:
What happens if we cross-reference them? Matrices are one of the most important tools in the architect’s bench. Matrixing these two lists gives us:
At first glance, it seems that all the activities have some system support, so we might reasonably ask, why an ALM system? Taking this question back to the application managers, we find that our first cut at the activities isn’t detailed enough. “True,” they say, “the ITSM system has a concept of Release. But it is a relatively high level concept, and the workflow is nowhere near flexible enough for our work. We’d like the new system to be our primary vehicle for managing releases, although we can continue to feed the ITSM Release system with our Release data.”
“Also,” they say, “the Defect/Issue Management ‘system’ we have is actually just a Sharepoint site and the workflow has never quite worked right.” In the spirit of doing “just enough architecture,” we then elaborate on that part of the development lifecycle a little bit:
First, we added the new column for the proposed Application Lifecycle Management system. The line item for “Build and deploy application” has been grayed out, since it has been decomposed into the sub-activities of interest here (italicized). We’ve added P for Primary and S for Secondary on where tracking releases will occur as well.
While I picked on the Application Lifecycle Management category here, the above technique can be applied to any system you might be thinking about bringing into your environment. And there are other lists and matrices we could consider. A data architect would key in on nouns like Application, Project, Release, and Change, and might ask what systems are mastering those entities. A more organizationally minded person might ask where the handoffs are between Application Development, Infrastructure Engineering, and Operations. Both of those inquiries could generate further lists and matrices. Finally, any list or matrix can be represented graphically.
Find out more in my free Webinar on Thursday, March 8th – Too Many Tools! How to Integrate Your IT Management Infrastructure