Does Digital Transformation Just Mean Swapping a Few Big Silos for Lots of Little Silos?

I’m not sure there is one, single definition of Digital Transformation but I like the one below because, like velocity, it makes reference to direction and movement rather than a point in time.

According to Elena Storozhkova of Perfectial, “Digital Transformation is the force that moves business forward” (see https://perfectial.com/blog/digital-transformation-strategy/ for the full article)

After all, there’s not much point in going on a journey without going anywhere, is there?

But with the relentless focus on Digital Transformation , there is also a growing realization that big doesn’t mean best. There are plenty of references to the fact that big transformation projects are high risk and often don’t deliver. McKinsey’s research has shown that as many as 45% of Rip and Replace projects fail. Almost half. Not great odds when your stakeholders or constituents are looking for the next big thing.

And the pesky thing about this digital age is the speed of communication – if something goes wrong, everyone knows about it almost instantly. And everyone can immediately share their ‘coulda / shoulda / woulda’ views with the world.

Fortunately, as the realization that BIG is not necessarily BEST was dawning, the Agile movement was growing in strength. From it’s early beginnings in 2001 and the formulation of the Agile Manifesto (https://agilemanifesto.org/history.html) focussed on software development through to more recent extensions to Enterprise Agile in the context of large programs of work such as the work being done by Macquarie Bank as described here: https://pe.ga/2oqrfd4

Great! Problem solved – just use Agile for everything, never do a big project again, she’ll be right mate (as the Aussies would say)

Except that if large organisations rapidly build small applications for a diverse set of requirements, the result will be lots of little silos instead of a few large silos and the end result may well be as bad or possibly worse than the ‘Big’ projects of yesteryear because they may need a broader range of skills and infrastructure.

But now we hear this problem has been solved as well: We’ll just turn our little silos into micro-services. Lots of independent pieces of logic that can call/interact with any other micro-service or be chained together to replace some monolithic application with a better macro service. And with containerization going fully mainstream, we can deploy these microservices faster and more efficiently than ever before so we’re good, right?

Not exactly. What this doesn’t talk to is how to make the process of building micro-services or apps or anything else more efficient. How do we prevent the Snowflake syndrome where the solution to every problem is a new set of micro-services. Seems like we are simply going back to the earliest days of coding. Great fun for the technically minded but not much else.

What we need is the best of both worlds. A large, robust platform that has all the necessary components to solve those BIG problems but which can be delivered in an agile way using the latest DevOps techniques. Something that can scale not only vertically for the largest user population but also horizontally to all the use cases an organization has to address.

This is mandatory in the public sector. Governments HAVE to provide big solutions that cater for everyone. They HAVE to address every use case mandated by their Act or policy.

The NSW Government is well known for it’s digital vision. During the release of its budget papers in June 2019, a ‘Digital Restart Fund was announced. Greg Wells, the state’s Chief Information and Digital Officer said this would include IT projects that promote “the adoption of common platform across government to remove duplication and increase efficiency” He went on to say that the fund will be used to progress agile projects that have the potential for reused rather than big bang, waterfall-style projects.

To be able to scale horizontally, i.e. address more business requirements with the same platform, reuse is not just implied, it is mandatory. No matter how efficient a development environment is, if everything has to be rebuilt every time, it will never scale to the level government agencies require.

Ok, are we done yet? We know we need to be agile, we know we need a platform that supports reuse. We’ve taken this on board and are ready to deliver.

There’s just one more minor issue we need to address – control. Who decides what gets reused where? If I designed the original component, do I need to pay for it to be tested everytime someone uses it in their application? Should I just be able to change it as and when my requirements change? In the context of large organisations or government agencies, this is a major roadblock to reuse. Unless there is a way to have centralized control but federated configuration capabilities, it won’t work. We need to have a platform that simultaneously manages a central, common function but supports the variations that each agency requires. A platform that supports the framework of the puzzle and the rules on where and how the pieces can be added but lets each agency take responsibility of the individual piece or pieces.

Take the example of testing eligibility for a license or permit. To drive a car, I need to have met my driving hours quota, passed my tests, and have no disqualifying medical conditions. That’s easy enough to build into a form – answer yes to some questions, present yourself at the eye test, along with your logbook and ID and you’re away. To get a permit for a major music festival is entirely different (as it should be) and yet the underlying process is the same – what do you want a permit for, do you have the necessary documentation or are you willing to sign a statutory declaration and have you paid your fee?

And yet how that would be implemented is vastly different; For a start, it requires a very different set of integrations between systems and data from different agencies to deliver two different outcomes in a truly digital ‘Tell Us Once’ experience.

To operate at scale, each of those diverse agencies needs the ability to manage their specialised piece of the puzzle.

And that’s where Pega comes in.

• Agile delivery? Check! – built into the development environment itself.
• A platform that supports reuse? Check! – across any number of levels and we have the patents to prove it.
• A governance method that supports centralized management and federated configuration? Check! – and all delivered in the cloud so no issues on shared infrastructure etc

But above all, our software is built to scale. To scale up to support large user populations and across any number of government agencies and use cases. To learn more about it click here: https://www.pega.com/technology/scalable-software

Or come to visit us at the Gartner ITXPO on the Gold Coast in October.