Architecture Standards and the Entrepreneurship Trend

There has been a recent trend that encourages entrepreneurship, or intrapreneurship to use a recently made up word, within the organisation. There is very little in the way of entrepreneurial activity that now happens without the aid of technology in the ‘new economy’.

Many organisations have very much un-entrepreneurial architecture teams, arguably rightfully focused on stability, that maintain a standard set of components or platforms that applications must be built on to result in as rational architecture as is possible. Anything that built on a platform falling outside this approved list, whether it is because of an active decommissioning effort or because it didn’t make it in the first place is rejected outright.

These very two areas can clash when entrepreneurial behaviour is being encouraged in the enterprise.

Despite what it may seem the very point of having a set of architectural standards, no matter if that is diagram formats or approved building blocks for the constructing applications, is to maintain consistency and simplicity. Consistency is good for everyone as it makes everything easy to understand. Simplicity reduces cost. Reducing operational cost is the key driver for maintaining a list of approved building blocks as more technologies means more operational specialists increasingly spread thinly across those technologies increasing the cost of running the organisation, something which is regarded, at least in the architecture and operations communities, as a very bad thing.

Entrepreneurship really thrives in an environment where the entrepreneurs are allowed to do it their way and are able to fulfil their ambitions which can be varied. Typically this mostly means taking the path of least resistance in the ‘how’ – making things happen, the ‘what’, means far more than fitting in with standards weighs which ranks pretty low by comparison. In larger organisations this is compounded by the fact that these endeavours are usually largely unrecognised from a budgeting perspective running as skunkworks and proceeding as a labour of love – a category that architects struggle with as they prefer to work in very structured environments and tend to need to do strategy work in any free time they do have. Decisions in the technology domain, therefore, seldom have the opportunity to be influenced by any sorry if list, whatever its motivation.

The question is how to best balance latitude to make things happen without undue friction, and the governance of approved standards?

The biggest issue I see is the perception brought about by approved standards is that they are suffocatingly restrictive. The architecture community within the organisation mustn’t lose sight of why the standards are there in the first place. The very reason for their existence, as most if not all artefacts, standards and processes in the enterprise, is to make the organisation more profitable- in this case by lowering the bottom line. They don’t exist so the architects have something to disapprove of, to deny, or to control, as it so often seems. Architects often forget to explain this part.

It has to be asked if the CEO will genuinely care about the fact that a building block is not approved when a small (or large) fortune is being made? In such cases the architecture community is likely to be told what they can do with their standard.
This is not to say the list shouldn’t exist. It very much should. The list should be broad and open to influence. Going off list certainly shouldn’t close the door to any architecture support.

Typically the approved building block list is separated into five tiers- ‘approved’, ‘under evaluation’, ‘by exception only’, ‘not approved’, and ‘end of life’. Examples of all but ‘not approved’ will certainly exist in the enterprise’s architecture. The chances are that there will also be a good few cases of ‘not approved’ blocks in the architecture somewhere, not because the architecture community sanctioned them but because someone ‘higher up’ told them to put them place, usually accompanied by a very vocal and largely ignored protest from an architecture community trying to enforce the list.

From an operational perspective these tiers broadly translate to ‘we can support it and have the people’, ‘we’re trying to work out if we have to or will find it easier to support it as well as trying to understand what we need to do about our people’, ‘we don’t want to support it but we have to and will do so with a small number of staff on a minimal basis’, ‘we won’t support it and neither do we have the people to’ and ‘we used to support it but don’t plan to in the future and are trying to redeploy or release the staff that do’. This makes sense as it keeps the operations organisation as tight as possible whilst also providing the most significant coverage of the most commonly deployed components.
So if an entrepreneur wants to use something not on the list then assuming that he can convince the powers-that-be to force the architecture and operations communities to have it placed in the ‘by exception only’ bucket and operations will be required to build a suitably minimal support function for it. Simple isn’t it?

Sometimes but not always. The support from senior leadership often comes once the entrepreneurial idea has gained some reasonable traction which usually means it must be ‘live’ for at least a little while. By this point the technology that has resulted has been in ‘production’ for about the same amount of time if not longer, skipping any discussion with what are generally perceived to be unreasonable architecture and operations communities. The technology is at this point running under someone’s desk or in a ‘credit card cloud’ and being supported by a small devops-like function. This function is well away from operations and stretches those involved beyond what could be considered reasonable- truly a labour of love. It’s more a case of developers doing operations rather than a close relationship and an overlap between the functions.

There usually isn’t enough reward attached to doing this in enterprises compared to start-ups unless the motivation is to gain visibility or accelerate climbing the ladder- neither of which are usually particularly strong motivators for developers. Good developers are inherently lazy people, it’s what makes them good at their jobs. All-in-all this really can’t be doing anything but hampering the very entrepreneurial spirit that the same enterprises are trying to foster.

Is there a happier middle ground?

Maybe what needs to be done is to add another life cycle classification for building blocks that means that although they couldn’t be expertly supported, they wouldn’t result in a beating for anyone trying to use them. Consumerised platforms such as ‘private’ clouds help to a large degree as somewhere for technology to live. Operationally, this would require the construction of a small team of operations generalists to support the technology on a minimal/best efforts basis. Most of the ‘not approved’ items would be moved to this new classification unless there were significant security issues or they were beyond vendor/community support that would firmly classify them as ‘not approved’. It’s arguable that versions may have a ‘not approved’ classification but platforms as a whole generally couldn’t.

The architecture communities also need to be proactively supportive of such initiatives, rolling their sleeves up and getting involved in making things happen. They must also take up their rightful position of trusted advisors to the organisation, especially in such entrepreneurial initiatives, rather than seemingly finger-shaking residents of ivory towers. Failing to do so runs the risk of the same communities becoming fossils from the previous organisational construct as the rest of the world evolves.

 

Leave a Reply

Your email address will not be published. Required fields are marked *