In February, the digitalML team had the pleasure of attending, and presenting at, SwitchOn’s European Enterprise Architecture Show. It was an insightful day, with excellent talks on a range of topics in the EA space.
I noticed a few common themes throughout the day, including:
- the evolving EA role: including the importance of ensuring business visibility, language and collaboration, and building trust between EAs, IT leaders, and business leaders
- the growing complexity of managing an expanding number of microservices, while needing to untangle your existing “IT spaghetti”
- the value of business capabilities, and a capability approach to digital transformation
APIs (plus Services, Events, and Messages) are core components of all of those themes and uniquely able to help you as an EA become the connective tissue that links business and IT, exposes business capabilities, and deliver on business and IT needs.
That’s why myself and Collin Rafter focused our presentation on how to align API programs to these important aspects of the evolving EA role and approach to transformation. The outcome? APIs as an interface into business capabilities, not applications or IT systems.
As a quick note on terminology, I’ll refer to “API” from here-on-out as an umbrella term for APIs, Services, Events, and messages.
To recap what we presented on the day…
APIs and digital are here to stay…
The train has left the station for enterprises on the core aspects of digital: transformation, API-, and cloud-first investment. Executives are buying in to:
- speed time to market
- take advantages of digital opportunities
- decentralize and distribute composability across the organization
This is largely working, and it has made life simpler for consuming applications and consuming developers.
But of course, there’s different levels of maturity across enterprises and industries. The more mature your practice, and the more widely available your portfolio of micro-applications and APIs, the more this works. It’s a fly-wheel of ever-expanding functionality. Forrester have a good outline for this maturity; moving from tactical and “used out of necessity” to transformative and “building blocks for platform business models and ecosystems”.
Well-funded digital and business opportunities are driving technology investments and development priorities. Some are working and are compounding investments.
…But most API development effort is still project and initiative driven
The main roadblock to this maturity I see often is API development effort still being project/initiative driven. APIs developed to support an initiative, but the design decisions are often expediated in favor of releasing at least an MVP product and moving onto the next priority. Business capabilities, reuse, and good design come second to speed.
The impacts of this approach are felt in a few big ways. You often end up with a nice front-end to functionality, but it’s complex under the covers.
That complexity is then amplified when you factor in the realities of a modern digital enterprise:
- working with composite APIs: bundled together from multiple providers for multiple consumers used to provide that pretty interface
- operating, testing, providing, and managing your growing API and micro-application ecosystem
It’s hard stuff, and contributes to a fracture enterprises are balancing…
Enterprises are balancing a fracture
There’s been a push to let developers develop, with the idea that an API will be short-lived. But there’s a dirty secret I bet your enterprise is hiding too: it’s just inherently hard to throw things away in a large org! That further adds to the complexity; support when something breaks.
Imagine a front-end problem, traced to back-end services and network effect that comes with streaming together APIs and Services from different systems and different ages. How long would it take you to get to the route of the problem?
Customers, partners, ecosystems, and markets always want more – and there is never time for it.
Asking your customers to wait a week while you troubleshoot an issue, or wait 9 months for the next feature while you’re revamping your back-end system doesn’t work in this new digital business model.
That’s why it’s so important to move away from the myth that just building APIs as your projects execute, and treating them as an IT concern will end up with a portfolio of composable APIs.
You can get to the target model by treating APIs as an interface to the capability
Here at digitalML, we see these markers as the target for API maturity:
Where:
- APIs are treated as an interface to a business capability
- The same capability can be reliably accessed as an API, Service, Event Stream, or Message – depending what your consumer needs at that time
This approach connects business capabilities, Enterprise Architecture, customer journey maps, and business process models to your distributed integration layer.
Fundamentally, business capability-driven API identification, prioritization, and development gets everyone on the playing field. It helps the business and IT collaborate effectively, with your Enterprise Architecture being the connective tissue in enabling (and baking-in) repeatable, predictable, scalable solutions. Creating a top-down approach, but maintaining support for bottom-up too.
And that’s valuable – for you and your customers
Aligning your strategic capabilities to your API program reaps the following rewards:
- you can capitalize on the promises of the API ecosystem – rather than ignoring your complexity and distribution, you’re unlocking and embracing it
- you’re reducing the costs associated with versioning and updates/edits, supporting multiple customers, changing formats, and deprecation
- you’re focusing API development on core value
- automated underwriting vs underwriting logic buried in monoliths
- you can create differentiated customer experiences – fast
And there’s more good news: treating APIs as an interface into business capabilities follows a well-defined process, and there’s tooling to help you mature quickly. It’s often up to a small and changing architecture team to fill a hole in the reference architecture and put in more structure to support the internal and external ecosystem, enabling this business capability approach. Our ignite platform can support you do just that:
- providing a holistic view of all API types with extended lifecycle management
- abstracted capability views of API designs, tied to technical specifications
- automating API design, governance and standards, validation, security, artifact and documentation generation, deployment
- integrations to your existing IT infrastructure
Access the recorded presentation below for more on these themes. Collin takes us through a platform demo from 15:18 if you want to jump straight in to the practical approach to aligning your business capabilities to your API program.
Watch the presentation on aligning your business capabilities to your API program
