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.

An agile mindset is not optional

Agile seems to be one of the most over-used words in business these days. For example:

Agile development 

Agile marketing

Agile architecture too ;-)

Done well, agile can produce prototypes and products very quickly and efficiently.

Done badly it can be an excuse for reducing the amount of time to create quality software or as a justification for only delivering partial functionality (for all of the budget).

Overall though... agility is a mindset, a way that organisations approach the task of creating value or improving the processes and products they have. And those that do not apply agility to their core will find they are not able to respond quickly or well enough to an increasingly swift competitive environment.

Or put another way.. which company wants to states as their vision or values that they want to be less reactive and more long-winded?

The Agile Architect

The technical or solution architect who has to align to an agile delivery methodology has a lot on their plate. In fact I have even recently written a post on The Agile Architect's Dilemma on Linkedin about the internal tug-of-war I am having between my agile and architectural approaches.

3 key areas they have to consider are:

Scale-ability / Scaleability:
To a certain extent this issue has become less of an issue with cloud-based services that have elastic capabilities to grown on-demand a volumes increase. However bottlenecks and latency can create problems, especially when using multiple different cloud providers or when API's are large & painfully slow. In short, not everything scales easily or linearly.

Micro-services / Microservices:
Rather than have monolithic points of integration (e.g. the above mentioned large APIs) the services that connect your different systems should be light and just based around specific functions. These micro-services allow incremental change and improvements to be made over time and better supports evolving front-end user experience requirements too.

Central data source:
Almost inevitably a digital architecture will need to store data in a single and centrally-hosted data source (e.g. a database). This repository of customer and operational data will need to be flexible enough to accommodate growing changes in storage and real-time data access requirements. However, no database (especially optimised relational database systems) can be expected to constantly change as the input and output demands of an agile development change too.