API granularity

Deciding how to design a digital architecture that provides optimum agility and scale-ability for your organisation is a challenge for many architects in the midst of a digital transformation. Deciding if you should use APIs in your integration layer is perhaps much less of a dilemma (hint: of course you must). But then working out how to design those APIs and the services behind them can be a new problem to solve.

I think this is an especially important decision, as it is quite hard to undo an architectural choice. Issues, can subsequently occur such as:

• performance bottlenecks (e.g. from too course a design)
• too much 'chatter' (e.g. from too granular a design) 
• the inclusion of too much (any?) business logic

All of which could have major implications in the future.

Customer Data Platform - Some Key Requirements

There's a growing trend in the digital industry to create or use Customer Data Platforms (CDPs). I will be hopefully covering this technical solution in future posts. However in the meantime iIf you are looking to implement one, here are some key (technical) requirements to consider:

• It provides a central unified customer data repository
• It allow simple / easy integration from a range of different data sources
• It supports a decoupled digital architecture, ideally via web services architecture
• It is able to elastically scale as demand and integration needs grow
• It is is resilient e.g. it provides fail-over (cold or warm) to separate disaster recover locations

Digital Architecture fundamentals

As part of a recent project, I was asked to come up with some architecture fundamentals of a digital system (not just a one application system, but a more complex and integrated solution assumed to be for a larger organisation).

Here’s my list:

• The architecture of a system or integrated systems needs to align to (or fit into) the overall ‘As-Is’ and ‘To-Be’ enterprise architecture of your organisation.
  
• Those creating the architecture need to first understand the business goals (e.g. the customer experience and commercial aims) and the major applications that ‘the business’ are likely to need in the medium term or have signed longer-term contracts with.
  
• A loosely coupled architecture provides the flexibility to use best-of-breed solutions from a range of vendors. The opposite is that either through design or legacy system adoption, your architecture shackled to one key supplier who is then possibly also integrated directly to multiple other systems… this obviously creates a dependency upon this key supplier, making them harder to subsequent remove and replace. Adopting a loosely coupled architecture also means you are not tied to specific front-end software, allowing your organisation the flexibility to either buy or build (typically using agile product & developers) to create the best user experience possible.
  
• Where possible, create a single in-house database, that can be updated by any other integrated systems… ideally in real-time. You don’t have to store all data that exists in every other integrated systems in this central repository, just those that you may need to align other data to at some point in the future.
  Note: It is possible that this service could also be provided as another integrated system, but for overall speed, agility and ultimately data ownership you may find it best that this database sits within the boundary of your main architecture. However, this does come with additional considerations: there is an overhead in managing and administrating a significantly large database, plus the data model used needs to be sufficiently flexible and scale-able to handle a variety of requirements over time.

Failing to Architect with Agile is Architecting to Fail

Agile approaches to development and online product delivery are almost de-facto these days. Every private and public sector organisation wants to be transformed, nimble, lean and able to deploy digital services quicker and quicker to their ever-demanding customers. And it is not just in the IT coding department that there’s been a change in vocabulary. An agile approach can even be adopted by a company’s commercial team, marketing department and even some of their operational functions (plus don’t even get me started on how much senior managers, procurement and HR have to change too – but that’s something for another post).

But I’m going to stick my next out (once again) on a subject I’m passionate about… Technical Architecture and how it clashes with agile delivery.
Or more succinctly put: Agile Architecture Doesn’t Work

There, I’ve said it now and I’ve been wanting to say it for a while. It has been on my mind as I’ve heard the opposite mentioned in podcasts, or read about it in blogs and books.
I guess I was trying to get this off my chest when I wrote my recent blog post “Digital Transformations starts and ends with Digital Architecture”. As in my mind, the science (or is it art?) of crafting a robust yet flexible technical architecture that supports digital business aims is the one thing you can’t build as you go.

Creating the technical architecture for your new venture takes planning. You also really only need one Technical Architect, the person who owns the architecture and has the responsibility for its solution design and ensures re-use of common components. Not a bunch of developers who all want to create a part of the architecture they are responsible for.

It’s like wandering around on a gap year between school and university (or school and work, or university and work).  You may be able to make up your journey as you go, with just you or a travelling companion making the decisions… but the roads and the map are pretty much fixed.

So...  although some agile practitioners talk about how agile approaches can help architecture deliver quicker or better.  I firmly believe that it is architecture that facilitates faster and more robust agile delivery.

Digital Transformation Starts and Ends with a Digital Architecture

The implementation of business transformations within organisations, and especially digital business transformations, is growing to a peak level right now. Chief Information Officers and Heads of Transformation are stepping in to: “digitally enable businesses”, “implement customer self-service channels”, “put the customer at the centre/focus” or just to simply “be more digital” (whatever that means).

However, when you ask these organisations what they are doing to change their internal systems and technical architecture design to facilitate this change, many either go quiet or simply utter something such as “it’s not about technology, it’s mainly about people”… Which I have worked out to actually mean “that technology stuff isn’t as interesting as building something nice & glossy I can show to the board”.

But let’s flip this around for a minute…

Digitally enabling your business usually means taking control of the data in your organisation and enabling it via online technologies. Yes, it does therefore mean the creation of some sort of new database or cloud-based big data lake that can then have modern web services integrated to it, so that some or all of this can be presented within a browser interface.

Implementing customer self-service channels, typically boils down to pretty much the same thing.  Web services and functionality are (securely - obviously) exposed to external customers via web and mobile App channels, so that contact centres or telesales operations can be scaled back or redeployed to different tasks. This also usually comes with a more onerous set of performance & availability criteria, so that a (near) 24/7 service can be offered to customers. However, presenting these services to real users also means that the systems behind-the-scenes need to be able to scale and adapt to changing user demands. Just plugging a rich user interface into a legacy system and hoping for the best is not digital architecture, it is digital anarchy.

Putting the customer at the centre of a business is an easy thing to say and a much harder objective to implement. Most organisations have been created to make money and therefore have lines-of-business designed to perpetuate this purpose. Consequently, technology systems are developed to support these structures and maintain the status-quo, rather than re-orientate things to make sense to the customer or help facilitate their engagement. It might be the ideal, but very few companies actually have end-to-end integrated systems that enable a single customer to be consistently tracked throughout their entire lifecycle. In short, creating technology to enable a customer to be in the middle of a business isn't always as easy as the sales PDF brochure states, especially if you don’t have a decent vision of how these systems need to work together.

So what can a decent technical architecture do for your company’s digital transformation?

It can provide a stable backbone that can support your technical & process change objectives. It can facilitate agile incremental delivery based upon re-usable components. It can help your business grow by supporting integration of other online services, API’s and data sources.

If you’re planning any of this, can you afford to NOT have the right digital architecture?