There’s a shift going on in architecture today, and it’s rooted in the base function of IT. The function of IT is, at its core, to build and then maintain solutions to problems. Ignore the technologies for a second and focus on that core functionality—“build and maintain.” When you wonder where that shift is going to take you, start by looking at other industries that parallel the “build and maintain” core functionality.
The IT industry, as it’s structured today, has been around since the mid-1980s. Sure, there were mainframes before that but, with the development of the personal computer, IT became something much more adaptable and modular. Honestly, it’s a really young industry. The advent of networking begin in the early 1990s, and then the Internet came of age in the late 1990s. So, really, IT is only around 30 years old.
Now what industry parallels the core functionality of “build and maintain” that is much older? The building industry does. The parallels between the building industry and the IT industry are extremely close. Both industries have their architects, though they focus on different technologies. Both have a core group of “property developers,” but in IT’s case, we are talking about the CIO and IT management. The general contractor in IT is the project manager. The tradespeople in the building industry parallel the administrators and the coders in IT. And, once a solution has been built, there is a need to maintain the end result, which is typically done by outsourcers.
No, if we want to know where this shift is taking us, don’t look at the technologies. Technologies will change continuously over time. Rather, look at how solutions are put into place and then compare the building and the IT industries. The building industry follows a business model where the property developers, who have property they want to develop, will hire a building architect to create a design, and then the building architect will provide oversight over the general contractor to ensure the design is implemented properly.
In IT, we currently see architects being hired on a “time and materials” basis for various projects. If an organization has enough projects, the IT architect will be a function brought in-house as an employee. But, predominantly, architects are a function used on a contractual basis specifically on projects. And, again, paid on a “time and materials” basis. That, my friends, is where the shift is coming from.
Outsourcing has been going on for quite a while because enterprises have realized that their core functionality isn’t IT, it’s whatever their market niche is. The IT function is something that is better done by someone outside the organization. But outsourcing is associated with the “manage” aspect of IT. It parallels the building maintenance organizations that you find in the building industry, and it charges a “fixed fee” for specific activities. Want a new server instance created? Here’s the charge. Want a firewall managed? Here’s your monthly cost.
The “build’’ is typically done by a solution provider that focuses on delivering projects. But the solution provider ends up having to work with the outsourcer to get technologies implemented. As a result, you get the solution provider and the outsourcer fighting because they both have a stake in the game and they are both typically rather inflexible. It’s also the reason why many outsourcers are using the “management of boxes” as a way of getting the much more profitable projects. They’ll know about the need for a project long before a solution provider does.
So where does that leave the architect? Let’s look at the building industry again. In the building industry, the developer will hire an architect who will put together the designs for the end product. In IT, I believe the shift will be to a similar model. Enterprises (or the outsourcers) will end up hiring the architect to create the design and then provide oversight with the outsourcer to make sure the solution is implemented appropriately.
The architects may or may not focus on specific product suites, and there are pros and cons to either approach. If you focus on a specific company’s products, you can get really good at delivering those products. But not all companies will want those products and, let’s face it, there are few “one size fits all” technology products. The other approach is that you focus on the requirements of the customer and then find the best fit. It may take a little longer to implement, but there’s a higher alignment of the end solution with the customer’s requirements.
So, if this is an accurate view on what the business model will end up being, what will happen next for IT architects?
Well, building architects bill based on projects rather than time and materials. It’s a “fixed fee” charge model. You already see this type of fee structure in larger projects that solution providers deliver. Why wouldn’t architects be charging in the same manner? I can hear the arguments already. “Architects do all sorts of different activities” and “No project is the same as the next project,” and so on.
But is that true? Yes and no. Yes, projects are different each time. But the WAY you deliver projects will be consistent. It’s the reason why we have architecture frameworks like TOGAF and Zachman. So if the way you deliver is the same, doesn’t that mean you should be able to standardize processes and templates and have rough estimates of how long it will take to deliver certain artifacts?
And before you argue with that, I will point out that most enterprises that have architecture practices internally do exactly that—they make use of standardized templates and processes in order to have some consistency of deliverables.
Now, if you have standardized processes and templates, and you combine that with architects being a function that is brought on by “developers” on a project by project basis, isn’t that a foundation for an architecture firm? They have that in the building industry; developers go to architecture firms for their designs, and the architecture firms charge fixed fees for end solutions. So why not in the IT industry? The only reason that it hasn’t caught on yet is because of how young the IT industry is.
Now that we’ve agreed that architecture will end up as something that the enterprise’s IT management will bring in, let’s talk about some of the artifacts that the IT architect delivers. The logical grouping of those artifacts may determine if you are talking about an enterprise architect or a solution architect. The domain architect will do the same things, regardless of whether they are an application architect or a security architect or an infrastructure architect. Those activities end up being the services that you deliver.
There are three logical layers of activities.
- The Governance Layer is typically owned by the chief architect or the enterprise’s IT management. That’s where you talk about architecture policies and standards, architecture guidance documents, and architecture principles. This layer provides the oversight over lower levels like architecture strategy activities or project architecture activities. And please don’t tell me you haven’t seen those functions being filled by contractors.
- The Program and Strategy layer is where things like key decision documents, architecture strategies and road maps, white papers, and current state assessments are done. Again, these are things that have been done by contractors. You can’t tell me that you haven’t seen one of the Big 4 consulting companies come in to create strategies for your organization. Isn’t that, at its heart, what enterprise architecture is, regardless of the domain?
- The Project Delivery layer is what the solution architect would do. If you look at the standard waterfall methodology, you’d have things like requirements gathering, vendor selection (though this could be done at the Strategy Layer if you are following a best-suite approach for your organization), solution architectures, test plans, and build documents (amongst others).
Every activity that I’ve identified is something that typically can have a standardized template and that you do the same way each time. If you do it the same way each time, then you have a standardized process and can give a rough estimate on the effort for each activity. And THAT is the basis for providing “architecture as a service” for a fixed fee.
So, architecture is shifting, and it’s shifting away from the enterprise to a business model where IT management will hire architecture firms to deliver architecture artifacts and provide oversight while their designs are implemented by the outsourcers. The only question now is who will be the Arthur Erickson of the IT industry? A&G
