By Ben Clark
This is an unusual post, as I wanted to talk about something that did not work, and why this and a few other things that did not work brought me back to focusing on Solution and Enterprise Architecture Recruitment.
For those unfamiliar with the concept, Architecture as a Service (AaaS) is a model designed to provide a company with flexible resources, artefacts, methods, visual design, demand management and other related services.
The theory sounds great, and combining our outstanding architecture network, agile architecture management style and unique take on architecture visuals really should have been a huge winner. The idea was even mooted by our clients, who asked us to design it in the first place. We produced a great model; however, for reasons that will become clear, true AaaS does not work.
The short version:
I realised very quickly that for an on-demand resource model to work, you would need more than one client to sign up for it. If the idea is to have someone put together an HLD for an application migration, for example, and that only takes four to six weeks, what happens for the rest of the time? If you are using an associate model, you have little control over what the person does next if you do not have work for them. If you have a permanent workforce, you will likely face a significant deficit if your team is not fully billed. It can only work if you have enough demand for the same type of problem.
Unless you are Capgemini or Deloitte, or even if you are Capgemini or Deloitte, there is a huge chance you are going to be putting round architecture pegs in square architecture holes. How many different types of architects are there? Some people will say five or six. I wish! The actual answer, the details of which are for a different day, is well over 50. So, what is the chance that one of your permanent architects will be available for that job at that moment? Very slim. So what do you do? You allocate the resources you have available to that assignment.
For AaaS to be effective, there must be a degree of knowledge retention. Otherwise, for each assignment, someone is starting from scratch; a member of the client team has to be involved in the onboarding, and the consultancy architect takes much longer to get up to speed.
Knowledge retention can realistically only happen in two ways: either a permanent PMO manages the sign-off of all deliverables, oversees the demand pipeline, maintains the library of artefacts and serves as the custodian of the work being delivered, or an all-round Lead Architect handles all of the above and delivers a significant portion of the work.
The problem with both is that an XaaS is supposed to be on demand; you are asking for an upfront and ongoing investment just to set up the service, which every client baulked at. As much as architects will hate to admit it, they do not have a clear understanding of their pipeline, as very few companies have a strict front-door policy for architecture requirements, so they do not know what, if anything, is coming. AaaS seems great because it means you can be flexible, but that flexibility needs a backbone to work.
If you work closely with a client daily, you tend to gain a good understanding of how long it will take to produce a specific deliverable or artefact. However, if your only interaction is a weekly or monthly 30-minute call, you are guessing how long something will take.
Clients do not like it if you are vague and include a lot of contingency. They want to know the exact cost, but because they rejected the concept of a team providing knowledge retention, we are all somewhat hamstrung unless the problem is fairly simple and you are prepared for a back-and-forth process over a few weeks to get the SoW right. I believe IBM had an architecture menu card that was as simple as ordering from a shopping basket. Great idea; the problem it had was that an HLD for one client was a design document for another, and it was only ever the start of a discussion, never something that was delivered off the shelf.
If someone has worked with a client before and done a good job, the chances are the client will want to work with them again. As mentioned before, this is all fine and dandy if Bob is, in fact, available. What happens when Bob is not available? Will Sally or Chris be an acceptable alternative? Can they do the job in the same time and to the same standard?
It is not a massive concern if you have a substantial permanent workforce to draw on, but it undoubtedly is if you are reliant on associates in your AaaS team. How do you know your associate is not involved in other side projects? What if they have two or three days a week of other assignments? Things can get very messy very quickly if someone is not 100% committed to the job in hand.
It is pretty apparent to me now when someone is not entirely concentrated on the assignment. It causes issues, and it is one you have to guard against before any assignment starts.
Just focus on finding damn good interim architects from a very reputable source, like, I don’t know, Konvergent! See how we do it in Engaged Search – Associates.
