Multiple teams in multiple locations
Glue42 makes it easy for teams spread around the enterprise (and the planet) to develop pieces of functionality that work together. Done right and depending on the tools and techniques used, you can often develop a lot of apps quite quickly – our biggest client reports development times reduced by 50%. Managing and coordinating many fast-moving projects is challenging to deal with and has a number of dimensions. As well as developer and project management your QA, deployment and production teams have to know what is coming, your security and compliance teams need to keep track of who is entitled to do what, and your infrastructure teams need to be able to manage connectivity and capacity.
On top of all of this, and really the whole point of Glue42 Enterprise and its UX Integration model, there needs to be a consistent look and feel to everything that ends up on the user’s desk.
To ease these problems, Glue42 have evolved a governance model from our work with clients over many projects. Although many organisations will have a system in place our model addresses some of the specifics that arise from using Glue42 so that the productivity gains from the technology don’t get wiped out by process failure. Our white paper describes the issues we have found to be important while this blog explains how the process helps your teams.
Make things visible
It’s critical to have a process in place that records both what has been developed so far and what is currently being developed and what is proposed. While a significant subset of development may be within a particular LoB there will always be components that are re-usable across business functions (for example search tools, user identification, document management tools) so its useful for the process to be global. For sure, there will be people in any one business unit that know everything that is going on (or at least there should be) but that’s not enough to get real visibility across the whole enterprise.
Our experience is that it helps for the process to include elements of people talking to one another so there is more to it that just throwing everything into a database and using some workflow tools.
The repository of information that underpins the governance process should provide a language for communication, between different development teams, between development teams and deployment teams, between development teams and security teams; in fact, between all interested parties.
The governance team will have members from many teams so it’s important to define things in a way they can all understand and engage with. They need to be able to identify and understand what is there and available for re-use.
If you get the governance process right, you will actively encourage developers from different teams to talk to one another and to the other teams involved in delivering stuff to the end user.
At a basic level the governance process will provide a forum where people increase awareness not only of what is available now, but what others are thinking about doing, so they can build potential re-use into their developments
Some people are determined to learn by experience
It’s hard to maintain a balance between creativity and conformance and some people find it harder than others. There is a lot of value in encouraging people to benefit from other’s experience rather than learn from their own.
Reviews form part of the governance process. As well as reviewing details of data structures or text label colours these provide the opportunity to identify problems that have already been solved. If the governance team includes members with appropriate experience they can provide guidance and thus avoid the “many solutions to the same problem” syndrome.
Ensure that things work together
Runtime method discovery is a crucial tool for enabling components to be delivered into a system and just seamlessly work with the existing components. For this to work, methods and data types must be defined and used consistently and, most importantly, be defined flexibly with sensible default values. The API review element of the government process is key to ensuring this consistency, and again, provides a mechanism for experienced developers and designers to guide those less familiar.
A coherent user journey
Unaided, programmers rarely deliver a good user interface. The UI, both static (colours, placement, wording etc) and dynamic (context menus, workflow routes) need to be consistent in order to avoid confusing the user. There is no point in giving the user a context driven route from one application to the next if the mechanics of the transition are different every time. Reviewing these aspects, again involving people with experience, is crucial to achieving a good Glue42 enabled system that provides real value to the user.
Glue42 is a subsidiary of Tick42 – a rapidly growing software vendor and services organisation whose mission is to treat the user experience as a first-class citizen when integrating applications.
Glue42 Enterprise has been deployed into some of the most extreme mission critical environments and is currently licensed across 12,000 production instances.