Archi to the rescue – Reflecting on an IS Application experience

Reflections on use of an informal solution to enable the digital workplace. Using the Gibbs reflective model.

Description

I was assigned as the Solution Architect on a project implementing a cloud SaaS Application in a bank. In Enterprise IS transformation programmes, Semiotics are crucial. A picture is really worth a thousand words. When we tried to collaboratively work on Architecture diagrams, we quickly realised there was no common tool between the three consulting companies, the Bank’s closed use of EA Sparx for UML diagramming,  and the SaaS company. This quickly became a source of frustration and inefficiency as external parties could not be licensed to use the very sophisticated SPARX tool. Under severe time pressure to implement digital transformation for business I was frustrated that the design practitioners were resorting to static images and recapture, as each party needed to work on and their part of a shared solution.

Data privacy, and intellectual property concerns on the part of the bank customer and the SaaS provider were understandable but led to a major project delivery risk. Some system thinking quickly resulted in a solution. Fortunately, all parties had access to, and were required to use, a shared Confluence portal for documentation. As a long-time proponent and user of open-source applications I kenw we could embed Archimate Models on the portal to control access, while allowing the various parties to collaborate efficiently? This led to a transforming solution.  

I decided to introduce Archi, which is a “free and open-source visual-modelling and design tool for creating ArchiMate models and modelling sketches. Archi was initially funded between 2010 and 2012 by JISC as part of a national project aimed at supporting a programme of Enterprise Architecture in the UK higher education sector.” https://g.co/kgs/pxNG21

Feelings

I was a little embarrassed at how crude the initial implementation was, but optimistic that it would solve the immediate problem and improve the team’s working conditions. We relied on the solution selling itself, so initially there was extremely light governance. It was a relief to see how quickly the architects and design leads saw the diagrams, realised they could edit them and installed Archi.

Evaluation

I was pleased at the practical adoption, and how the Agile programme enabled the rapid adoption of the tool. Some crises in terms of delivery were averted by the more efficient collaboration.

Predictably, the trough of disillusionment followed. A tight knit team of five or six experienced architects consciously working around the risks of light governance, could manage. Then came COVID lockdown, and remote work, and everyone working collaboratively. We rapidly discovered that the operating model was not suited to scaling. To open access, we were obliged to implement some controls on access, and formalise the organisation and structure of models. Separating models into separate pieces made it possible to avoid contention and overwriting of work, at the cost of having to develop a catalogue of models.  

Analysis

In hindsight, I was so task focussed and content that we had a good enough solution, that I failed to take the time to mature and formalise the use of the tool.

Subsequently, other teams we have matured the use of Archi. Their much more sophisticated use resulted in the bank abandoning the expensive commercial product.

Learned that quick innovation is great, but success depends on having a roadmap of how to develop and scale. I was too informal on this solution because of project delivery pressure. With a little more application we would have had greater benefit. So definitely some regret at how we did this.

One of the risks of using a powerful tool is the many different approaches possible, but innovation needs to be balanced against purpose. People easily become infatuated with what can be done. One of our successes, getting business analysts and even manager to use our Archi diagrams was a gratifying surprise. Another pleasant surprise – self-service training, and simple language guides outperformed formal training. Self-motivation and some accidental gamification led to rapid capability development. Leading to greatly improved time to value. The learning method we were obliged to use informally, because of the constraints on face-to-face activities meant that we accidentally discovered that people learn very effectively from video. When we discovered users rewatching meeting videos to understand how we were modelling on Archi, we gained an interesting insight. Simple, short videos showing how to use a tool were much more successful than longer, formal training. This was not restricted to any demographic. Without any mandate of what and how, people adopted the tool to collaborate on conceptual and logical UML models, ultimately it has become an invaluable collaborative design and documentation tool.

Action Plan

I will definitely use Archi again. Digital transformation projects involve a broad range of stakeholders. Applying System thinking, and involving this broader community who have proven capable of engaging meaningfully with the diagrams and models that Archi produces. The lesson to build guidance into the implementation will be used. With templates and usage guides embedded, it should be possible to avoid the explosion of different ways of doing the same thing.

We enabled the digital workplace and empowered an ecosystem, collaborating with internal and external parties. Without incurring cost, that is something to celebrate and apply. I will continue to advocate changing business models such as the use of open source software, and cloud collaboration tools as part of our digital transformation approach.