The next evolution of IT consulting - Transition from IT to PRODUCT

A new generation of Product "Builders" will be making the next innovation push into consulting.

Ever since the outsourcing revolution began in the 1980s, companies have been counting on on-demand or staff-augmentation services of software developers, graphic designers and a whole range of other services to augment their full time employee ranks.

Outsourcing makes sense because it is faster in finding targeted resources for performing a one time project, or an ongoing project with an eventual end in mind. Outsourcing also hedges companies against seasonal and unexpected ups and downs in business without having to hire and fire employees which can be hard on all involved.

The challenge with the status-quo outsourcing is that it can become its own sink hole of resources that work on never-ending projects while the companies are trying to figure out what to build! Companies take on "augmented" resources and add them to an existing team which is managed by the same management in the company. This practice, if not managed and monitored carefully and continually will not only not have the expected results, it can add to ongoing challenging situations where accountability and security is much harder to maintain. Just because you remove (Fire) an outsources employee it does not mean the issues are going to be resolved by your internal team.

And a lot of this is caused and exacerbated by the old, legacy, monolith software of the 20th century, which is still running 90% of the world's corporations (my estimate based on my experience having worked at some of the largest enterprises). This is not a rant or a complaint - just a statement of facts.

Good news is that software, while eating the world, is also changing. The change started back in the 80s with SOA (Service Oriented Architecture) on legacy monolith software in hopes of (and with some success) minimizing build out of massive software applications.

The challenge is that even SOA ended up building "semi-massive" applications. Basically the services became smaller from the mainframe code level but still doing way too many things. And of rouse the entire engineering and IT organizations were built on top of this old monolith culture. That was the best and latest 40 years ago, but not in today's world.

The latest evolution of SOA is MSA (microservices architecture) which is not just a software improvement, even more importantly an organizational overhaul on how software is built and maintaned. We have some educational core work ahead of us related to microservices because the majority of developers and architects sincerely "beliueve" they are building service-oriented applications, and they are no complete incorrect by definition, and in comparison to fully monolithic applications. But in 99.9% of instances when I have dug into the services that developers have they are not true microservices. they still do too many things.

A microservice by definition is a service, and application that does "ONE" function (for example basic checkout of a shopping cart) and is addressable, or able to be called independently using an endpoint.

There are a lot of a smart people working on bringing MSA to the enterprise, from tools to commerce platforms, analytics and more.

So what does this have to do with outsourcing and consulting?

I believe the freedom and capabilities the microservices revolution has provided to us can, and should, extend into outsourcing.

Instead of augmenting your developers or project managers or other members of the team, augment, expand your product capabilities. Have teams build entire services, that easily plug into your internal services. Give them freedom of innovation and expect "full accountability." Let your consulting partners deliver "solutions" instead of just bodies. Solutions, working services generate revenues.

Invest in determining the "product" instead of code. and expect your partners to deliver complete, working "products", or services.

I understand this takes the control away from the IT and engineering and transfer it somewhat to Product but in all honesty, Products are what generate revenues, and what customers use, so all organizations need to be more Product-focused. Engineering is still an integral part of the process but they also must be thinking more product, than code.

The engineering and software leaders can be free to innovate on the organizational side and actually be more directly involved in product conversations and decisions - individual, specific products not massive applications.

Of course not everyone is able, or willing to go the new software way. And even if we do accept and want to do this there is work to be done to change. Change is always harder but it is necessary.

As executives we need to be thinking at least 5-10 years ahead in the technology decisions we make today. MSA and product-focus is the right way, the only way to be a fully agile and innovative organization 1-20 years from now.

Some of the direct benefits of a"product-focused consulting":

more accountability on the part of the consultants. no more blaming other teams for the project taking 2X schedule and budget. There will be changes but they will be much more contained and managable.

Less expensive:

Faster

Legal clarity

Cleaner governance

Challenges with microservices:

response time / lag - the most important challenge of building fully microservicable applications is the call-time added to send/receive data between services. This is manageable and we're just only beginning to address this issue with good results:

Examples of solutions

Old software / habits: this is the most real threat and challenge to the new software paradigm.

How to build full products as consultants?

Think pizza, -1 and 2 pizzas. Humor aside, the 1 and 2 pizza team format of the new product-focused companies lends itself best to build containable services for complete team. The pizza team is a fully functioning team capable to build a complete product, the functionality, backend, front end and ready to be inserted into the infrastructure of the organization.

The skills to build services are considerably different from just punching out code so team, all members of them, need to be re-trained in how new software is built.

We are lucky that technology such as the cloud, containerization, call-optimization and other core functionalities have been created, and continue to be so we can use them.