As I noted in my blog yesterday, transformational changes in technology buying by enterprises depends on the launching of new tech projects that unlock new benefits, unleashing new sources of funding. For two decades, the contribution of new benefits to IT budgets has fallen, to the point where today it makes up less than a fifth of its peak levels. Obviously, there’s something bad going on. Part of it is that we’ve picked the low apples of business benefits, making it harder to gain new funding, but there are other factors we can dig out, too. We can also get some insight into why new higher-apple projects are harder to launch.
The way that projects get launched has evolved through three distinct phases since the dawn of IT. In the first phase, which lasted from the 1950s through the 1970s, tech projects were normally driven by analysis of current processes and the way they could be improved. The technology to do the improving was known and often even already in use, and so we could call this a “harnessing” phase. The second phase, which ran from roughly 1980 through 2000, saw project opportunities known to exist (often by having been analyzed in the first phase) exploited when a missing piece in the tech puzzle came along. We could call this the “completing the puzzle” phase. The third, and current, phase involves project opportunities that require a rethinking of the way the business is done, a rethinking profound enough that it hadn’t been done in past phases. Call this the “business analysis” phase. This phase evolution, we’ll see, is critical to where we are in tech evolution overall.
My personal experience as a software architect spans all these phases. In the first phase, for example, it was common for companies to let IT organizations pick targets of “automation” because they understood tech capabilities, and so could visualize how they could be applied by observing current operations. Tech capabilities were understood, and applied. In the second, when something new came along (like the IBM PC) the new capability could be evaluated in light of past assessments, and it was easy to see where something could be done. In both these phases, we were technology driven, and we could assume that understanding the technology could quickly lead to recognizing how to apply it.
Not so the current phase. The problem here is that when a technology comes along, say “cloud computing”, the application of the technology will require a re-examination of the entire business process and technology framework to get a handle on a project approach and frame a business case. This, to me, suggests that the organization of a project team needed to change. In the first phase, companies had separate “programmers” and “system analysts”, behavior that in the second phase started to erode into a single “programmer-analyst”. Have we seen a change to accommodate today’s situation?
Not according to enterprises. In fact, until 2024 (at the end of the year), I didn’t see any statistically significant number of enterprises thinking about reorganizing the way they did projects. Since then, a dozen or so enterprises have talked about what one called a “cloud team”, a special group of IT professionals whose job was to frame projects for implementation via hybrid cloud. These teams, led by an experienced software architect and staffed by people with specific cloud development training/experience, did the heavy lifting that their companies had come to realize was needed for successful use of the cloud.
What sets the cloud team concept apart is that it presumes that the project to be assessed will be disruptive both in technical and business terms. It starts by cataloging where the cloud is different, then where the “differences” are likely to matter most in a business sense. I think it’s a great idea, but keep in mind that cloud computing is almost 20 years old (AWS launched in 2006), and we didn’t come up with the cloud team concept until 2024. Even now, use of a formal cloud team is down in the single-digit-percentages in enterprises. Interestingly, all my cloud-provider contacts say that, to some extent at least, they use the concept themselves in feature planning. None say they promote it to buyers, but of course there may be some influence exercised by cloud provider people I don’t interact with.
Where I have heard of more widespread use of a “team” concept is in industrial IoT. In fact, most enterprises in the manufacturing vertical, and about half of those in transportation and utilities, say that they develop applications with a team very similar to the cloud teams, but with the important addition of some number of operations professionals from the line organizations involved. I’ve worked myself on several of these teams in IoT applications in transportation and facilities management, but I’ve not personally seen them used in more general business applications.
Why hasn’t this concept spread more quickly, more broadly? Here I do have some personal experience. The user company I worked for the longest was, when I was first hired, letting centralized IT manage development and operations of data centers and networks. About 18 months in, they divided IT development up by major line of business, because line departments found the central group unresponsive. They went back to centralized when the divided IT proved inefficient, and ended up going back and forth several times. The point, I think, was that you have to view a “team” as a collection of people for a task, not as a permanent organizational element, and since both the line and IT sides of companies are organizational in structure, there’s a tendency to weaken teams in favor of organizational separation of tasks. Enterprise comments over the last several years, including comments from those with cloud teams, support this view.
AI seems to be a technology in desperate need of a team, and so is the empowerment of those missed 40% of workers I’ve blogged about many times. In one case, we have a specific technology in mind, and need optimal applications. In the other, we have a target mission, but not a specific technology. I wonder whether the role of “enterprise architect”, but strengthened, and in some cases offered co-leadership with the role of software architect. It got started at the right point, in the early 2000s when the concept of workflows, service-oriented architecture (SOA), and enterprise service bus workflows came along. Enterprises say it didn’t get, and doesn’t have, broad traction, and that where it exists the mission the role plays is inconsistent. It seems to me that enterprise architects should be the designers of business processes, and they should work with software architects to manage the automated side. All this would add up to what a modern project should look like.
Most enterprises can create a team to do a project, but not to consider one or to assess potential opportunities. Logically such a team should be under the CIO, and all the cloud teams I found were in fact done that way, but keep in mind that a cloud team has perhaps a more technical-assessment role, and those in place tend to look at projects already being done inefficiently. For my enterprise readers, I’d love to hear your thoughts and experiences on this topic.
I think that the teams concept is critical. There is no single formula for tech project success, because we’re not back-filling technology into recognized opportunity areas. With things like AI, we’re not just shooting at a moving target of opportunity, we’re shooting from a moving technology vehicle. Both, arguably, are moving randomly. It’s going to take a new level of cooperation.
What happens if we don’t get a team approach, or something else, that changes our magic ratio in a favorable direction? That would favor two things, incumbency and industry consolidation. Absent funding to justify major displacements, budgets tend to simply replace aging gear in kind, which favors whoever provides that gear. The fact that requirements aren’t changing because nothing is changing them makes feature differentiation more difficult, which means price differentiation and commoditization is likely. That situation in turn drives consolidation of vendors for efficiency.
The industry would be more exciting if we could raise our ratio. Jobs would be more interesting, stock prices would likely be higher, and in all good things could be expected. But it might take time, and that introduces a qualifier into our “could be better”, the qualifier being “in the long term”. Right now, long-term thinking means to the end of the current fiscal year. Is that long enough for this kind of progress to be made? Probably not, but we’ll see.
