Multivendor, Multisourcing and Architect Egoes
I was listening to an interesting program on NPR on the drive to work that featured “Technology for Unmanned Planes Shown at Paris Air Show” The program was about the technology from Athena Technologies, which makes flight-control and guidance systems for unmanned aircraft, and about how we could someday be flying on aircraft without human pilots. After analyzing a few aspects of technology, the reporter brought out an interesting aspect that could be a potential bottleneck in adopting the technology: Pilot’s ego’s.
This made me reflect on an aspect of offshoring that I did not delve deeper into in my book [Offshoring IT Services] is the dynamics of multisourcing. Infosys teams increasingly get involved in programs and projects for clients that also work with other vendors. Of course there are several dimensions to such interactions. Facilitating review of artifacts, say architecture and design outputs is an example. And here, similar to the Pilot, the ‘Architect’s Ego’ comes to play.
Case in point: I was making a presentation to a client in response to a proposal for an SOA solution recently when the aspect of architecture governance came up. The IT director indicated that they were evolving an SOA - Center of Excellence (CoE) for the enterprise and were looking to leverage our team in addition to another SI vendor they were working with.
A similar query was posed by my colleague in our discussion forum around the need to evolve a common governance framework by utilizing our practices along with that of the other SI vendor team:
In this instance, the client is looking for best practices in reviewing Technical Architecture & Design outputs by Infosys (and other service providers). The key objective is to train their internal IT workforce in validating the technical outputs. The best practices could be in form of guidelines, checklists or tools in place on client side. The key areas of interest are technical architecture, design and non-functional characteristics (stress / load / regression testing).
Such multivendor scenarios where architects and senior technologists from different organization work together are getting increasingly common. In these scenarios, some of the key aspects to focus on include:
- Standardized and robust governance processes
- Standardized and robust templates for artifacts to be reviewed
- Up to date and well documented IT Strategies and Architectures
Now, we at Infosys have credentials in these areas. Similarly, many large clients also have their own processes in place, just as other SI vendors who also work with the same clients. Though there is no cookie-cutter approach for utilizing frameworks or building consensus, such situations provide an opportunity for a consultative development leveraging the best practices and working together. Back to the Airshow story, this may also be an opportunity to keep a check on the Pilot (Architect) Ego: we may have a really good process but if the client and the other vendor also have a fairly robust and workable model, why not leverage that instead; right?
