2nd of 3 parts. Part 1
Disclaimer: this post represents my personal views only.
Let’s confront some of the harder frequently asked questions about IT4IT.
"IT for the sake of IT”?
“Oh, you want IT for the sake of IT? What about IT for The Business?” is one initial reaction we hear.
Of course, the business is represented in IT4IT. The IT4IT architecture reflects throughout the fundamental business drivers that give rise to the need for IT services. One sees Portfolio and Demand, going on to Requirements, Service Level, Request, and so forth.
Like ALL brands, IT4IT™ has its limitations. In all honesty, we went round and round on the brand. My initial domain name ERP4IT had influenced the IT4IT choice, but would have been even more problematic.
Yes, IT4IT implies a limited and specific scope. Does it solve the world’s problems? No. Is it of universal interest to all business professionals? Of course not.
Does it address the problems of a coherent and significant industrial “horizontal” domain? Yes. Again — Digital Transformation Is Important. The Business of IT is not billions, but trillions of dollars of economic activity. That name unpacks into quite an ambitious scope.
And there's no reason the IT4IT ecosystem can’t be expanded into a suite of variously-branded standards. By comparison, the TM Forum (more on them in the next post) has expanded and refactored its branded suite of standards over time - eTOM, NGOSS, FrameWorx, TAM, SID. I suspect some parallel, more “business-relevant” branding will emerge sooner or later.
"Too technical and specialized”?
A more sophisticated critique is that IT4IT is “too technical.” IT4IT describes, using enterprise architecture methods, the necessary systems and data architecture needed to deliver IT services. If you look at the standard, you will see concepts such as:
- Source Control Component
- Incident Management Component
- Portfolio Management Component
You will also see conceptual entities such as:
and their relationships. At lower levels of detail you will see Essential Attributes and very detailed system interactions.
From a business point of view, this is a solutions architecture of a supporting function (Information Technology). It is comparable to having a reference architecture for Human Resources, or Corporate Finance, or Supply Chain Management. It is also comparable to having a reference architecture for a business vertical, such as banking, insurance, retail, or telecommunications.
In a sense, IT4IT is “bottom up” as opposed to a “top-down” process and capability-based approach - but it is possible to start here as the IT industry has a number of consensus points. For example, it is clear that source control and package repositories, portfolio management and event management systems EXIST, along with a variety of related data objects. These are objective realities that can be described and can anchor the standard. Describing such realities is the purpose of reference architectures.
Towards a business architecture
By starting with essentially a solutions architecture grounded in current market reality, IT4IT has avoided – for now - difficult and too-often religious issues of process, function and capability. However, the “value streams”:
- Strategy to Portfolio
- Require to Deploy
- Request to Fulfill
- Detect to Correct
are the beginnings of a business architecture. The data architecture is primarily conceptual, not logical or physical. There is also a capability model, currently “non-normative,” also representing a form of business architecture. The standard can (and I think should) continue to elaborate these aspects.
In sharing the same organization as TOGAF and Archimate, IT4IT is at the industry leading edge of business and enterprise architecture. The initial vision is deliberately foundational - starting with tangible systems that can be acquired and are seen in the field, and concrete, meaningful data architecture. As the IT4IT Forum collaborates with its peer standards groups, I believe that a sound and well-formed business architecture at the capability and value stream level will develop.
Finally, I think the standard needs some kind of emergent/ evolutionary representation. Not every company is at a stage where it needs to formalize all the components and data objects suggested by IT4IT. But some things (source repos, releases, etc) are required from the earliest days of any digital enterprise. Can we define a reference model for how these things tend to emerge? (I think we can, it’s in part the basis of my latest book.)
Is IT4IT redundant with ITIL?
This question comes up a lot - in a word, the answer is no. ITIL is best understood as requirements; it is higher level and less structured than IT4IT. IT4IT instead resembles my first book, which was written as a conceptual architecture based on a reading of ITIL, COBIT, CMMI, and the portfolio and project management literature.
Yes, there are big gaps. GRC, IT Finance, Asset Management, Information Management ... come and help us!
IT4IT and Agile
The challenge to IT4IT I find the most credible is from the perspectives of Agile and web-scale IT.
Let’s start with the IETF/W3C approach to standards. These standards are based on “rough consensus and running code.” It’s a challenge that higher-order reference models struggle with. How do we demonstrate “running code” when the topic of discussion is abstract? Enterprise architecture is notorious for “going down the rabbit hole” of endless semantic debates. IT4IT is vulnerable to this. But it is not insurmountable.
As a leader of the Agile Workstream, I determined that I needed a practical simulation in order to make responsible recommendations. I had other reasons (my work as an instructor at the University of St. Thomas) to develop the Calavera simulation. But there were important outcomes for IT4IT, including the Forum’s acceptance of “Source Control” and “Package Management” components. Elaborating the standard via reference implementation is something I intend to keep working on.
Note that the core functional components in the Require to Deploy value stream (to take the most Agile-relevant example) do not drive or imply any methodology. If you are doing Agile based on a toolchain including Source Control, Build Choreography, Package Management, and Release Automation, you can see it in the standard. There's no requirement for you to use the Project Management or Service Request-related components if that's not how your company is managing its IT investments.
I believe that the most insightful thinking in the Lean/Agile world comes from the influence of Lean Product Development, in particular the work of Preston Smith and Don Reinertsen. Lean Product Development suggests priorities that can inform a reference architecture, for example:
- Managing queues and work in process
- Enabling feedback
These concerns have already, and will continue to inform at least my involvement in the standard; I can’t discuss work in process beyond that, outside of formal Open Group channels. (I will say however that the Agile Scenario should be published shortly.)
A related question from an Agile perspective is whether IT4IT is too influenced by waterfall and linear/sequential, Taylorist thinking that problems can be solved by specialization. I personally think the standard has some evolving to do on this front. IT4IT is intended to be broadly applicable to a variety of organizations, and must accurately reflect the operational reality of current IT management practice, especially in the larger enterprises which will be the most interested in it.
While cognizant of the future, the standard must also be useful to today’s practitioners working in a wide variety of IT paradigms, from legacy to full-on “unicorn” Agile. The reality is that large parts of the IT industry bought into ITIL, and so to be meaningful, IT4IT needs to reflect the fact that people do have Change, Incident, Problem, Service Request, and Configuration Management systems. One of my hopes is that we can use IT4IT to describe how IT organizations might transform over time...
Now there is much in Agile outside of the scope of IT4IT, especially issues of culture. These concerns are real enough, but are too intangible for a reference architecture to reflect. Again, IT4IT does not seek to be all things to all people.
To be concluded in the next post.
Next: IT4IT as a reference architecture