WANTED: Platform Architects

With the proliferation of micro services, cloud, agile, open-source and other engineering driven initiatives throughout enterprise IT the role of Platform Architect has never been more important. Here we look at just one area where the Platform Architect can provide immense value: choosing technology.

An emerging trend is for technology choices to be owned by a project and made in isolation. After years of technology mandates, engineering teams have finally been unshackled and they are taking every opportunity to use the latest and greatest technology for their project. Enterprise Architecture is typically only providing top-level guidance here ('promote cloud'), and without a detailed vision for the platform this technology free-for-all can often get out of hand. 

In general engineers are the right people to be making technology choices, however:

• Engineers often don't have information about the wider technology landscape. Use of the MEAN stack might mean that a project is delivered twice as fast, but it also means that that it can never be migrated to the .Net PaaS that the organisation made a five year commitment to.
• Engineers are rarely asked to consider the total cost of ownership of their technology decisions. Adopting Postgres might seem great now but how do we monitor and maintain it with out OEM GridControl infrastructure? What new tools do we need to buy? How much will it cost us to train staff who have never used this database?
• Engineers may be required to make decisions outside of their areas of expertise. A lead Java developer is exactly the right person to make decisions about the Java frameworks and libraries that will be used, but they may not be the right person to be deciding on the container solution for its high-availability production deployment.

Technology decisions should be made within a framework that both supports the decision making process, and aligns it with the platform vision. It's the Platform Architects job to put in place such a framework. Most importantly the framework should be accessible, and permissive: the goal is not to stop engineers using the technology that best suits their project, its to support them in their decision making process.

One of the biggest failings of high-level architecture is that its rarely well communicated to the people who have to implement it!

A simple traffic light system categorising technology into groups like Deprecated, Active, Encouraged, etc is a great start. Ideally each categorisation has a design decision attached to it. The design decision provides rationale for the choice backed up by architecture principals and supporting material. 

And a hypothetical example:

The next step is to make sure engineers can not only access this information, but to ensure they know about it. One of the biggest failings of high-level architecture, something I see time and time again, is that its rarely well communicated to the people who have to implement it! Sending out a 100 page architecture document every 6 months is not enough. One-way presentations are not enough. You need to be out there, walking the floor, engaging with solution architects, project managers, and most importantly engineers.