Innovation versus Constraint

2016년 10월 28일Malcolm2분 읽기

The following is not an unfamiliar story and it's something that the Architects in Emerging Technology Practices of Red Hat Consulting see on a regular basis. Technology choice which is based on ease of use, availability or specific functionality is not always the best approach within a large enterprise.

While it will make one project on-time and achieve its design goals, it potentially creates sprawl and a diverse technology landscape which will become full of technical debt and hard-to-maintain services. What might be best for developers can cause real headaches for operations who have to run systems in production.

However, the imposition of a specific set of products as part of a top-down road map (driven from Enterprise Architects or the Operations team) can also be counter productive as it restricts innovation and removes a level of autonomy from project teams and developers. (They want to work in a fun place, don't we all ? ). A happy medium occurs when regular dialogue between teams and enterprise architects make a defined superset of technologies available to teams delivered via a Platform-as-a-Service. This ‘walled garden’ ensures enterprise ready software and a limit on proliferation.

All gardens need nurturing on a regular basis, where development teams and enterprise architects, along with the operations teams do weeding (of out-of-date components) and planting (of new tools and platforms) on a regular basis. Everything in the garden should interoperable with the other components and be developed by the Operations team. These artefacts would be developed using a Continuous Integration for Infrastructure approach, so that Operations themselves would become more developer centric.

This wall garden of choice is something that predicated solutions like Red Hat Open Innovation Labs offer as part of its infrastucture, covering application platform, development tools and infrastructure components.

The challenge for an architect is in part putting the tooling in place to make sure that:

an easy to use tool for selecting components from the walled garden for a project
a means of ensuring new tools can be chosen and added to the selection list
a means of planning and then carrying out the deprecation of components in the garden

The environments will not just define the components but also the size. A predefined PaaS environment would offer set sizes, locations (on premise, public cloud) and other environmental options

The PaaS environment and the technology platform is only part of what needs to be done; the organisational, process and cultural change is more difficult. Challenges vary, starting with working out who is involved and responsible for the walled garden. There are a number of ways of doing it, but running it as a community of practice (CoP), that it on open source project lines, will be the best way of bringing the different parts of the organisation, with leadership coming from people who care and who are interested in getting as much possible benefit as possible.