The true scope of enterprise architecture

This article addresses what is, or should be, the true scope of enterprise architecture.

To date, most enterprise architecture efforts have been focused on supporting IT’s role as the ‘owner’ of all applications and infrastructure used by an organisation to deliver its core value proposition. (Note: in this article, ‘IT’ refers to the IT organisation within a firm, rather than ‘technology’ as a general theme.)

The view of the ‘enterprise’ was therefore heavily influenced by IT’s view of the enterprise.

There has been an increasing awareness in recent times that enterprise architects should look beyond IT and its role in the enterprise – notably led by Tom Graves and his view on concepts such as the business model canvas.

But while in principle this perspective correct, in practice it is hard for most organisations to swallow. So most enterprise architects are still focused on IT-centric activities, which most corporate folks are comfortable for them to do – and, indeed, for which there is still a considerable need.

But the world is changing, and this IT-centric view of the enterprise is becoming less useful, for two principle (ironically) technology-led reasons:

  • The rise of Everything-as-a-Service, and
  • Decentralised applications

Let’s cover the above two major technology trends in turn.

The rise of Everything-as-a-Service

This is a reflection that more and more technology and technology-enabled capability is being delivered as a service – i.e., on-tap, pay-as-you-go and there when you need it.

This starts with basic infrastructure (so called IaaS), and rises up to Platform-as-a-Service (PaaS), then up to Software-as-a-Service (SaaS) and finally  Business Process-as-a Service (BPaaS) and its ilk.

The implications of this are far-reaching, as this research from Horses for Sources indicates.

This trend puts the provision and management of IT capability squarely outside of the ‘traditional’ IT organisation. While IT as an organisation must still exist, it’s role will focus increasingly on the ‘digital’ agenda, namely, focusing on client-centricity (bespoke optimised client experience), data as an asset (and related governance/compliance issues), and managing complexity (of service utilisation, service integration, and legacy application evolution/retirement).

Of particular note is that many firms may be willing to write-down their legacy IT investments in the face of newer, more innovative, agile and cheaper solutions available via the ‘as-a-Service’ route.

Decentralised Applications

Decentralised applications are applications which are built on so-called ‘blockchain’ technology – i.e., applications where transactions between two or more mutually distrusting and legally distinct parties can be reliably and irrefutably recorded without the need for an intermediate 3rd party.

Bitcoin is the first and most visible decentralised application: it acts as a distributed ledger. ‘bitcoin’ the currency is built upon the Bitcoin protocol, and its focus is on being a reliable store of value. But there are many other protocols and technologies (such as Ethereum, Ripple, MasterCoin, Namecoin, etc).

Decentralised applications will enable many new and innovative distributed processes and services. Where previously many processes were retained in-house for maximum control, processes can in future be performed by one or more external parties, with decentralised application technology ensuring all parties are meeting their obligations within the overall process.


In the short term, many EA’s will be focused on helping optimise change within their respective organisation’s, and will remain accountable to IT while supporting a particular business area.

As IT’s role changes to accommodate the new reality of ‘everything-as-a-service’ and decentralised applications, EA’s should be given a broader remit to look beyond traditional IT-centric solutions.

In the meantime, businesses are investing heavily in innovation accelerators and incubators – most of which are dominated by ‘as-a-service’ solutions.

It will take some time for the ‘everything-as-a-service’ model to play itself out, as there are many issues concerning privacy, security, performance, etc that will need to be addressed in practice and in law. But the direction is clear, and firms that start to take a service-oriented view of the capabilities they need will have a competitive advantage over those that do not.






The true scope of enterprise architecture

Decentralised Applications in FinTech

The new ‘Decentralised Applications in FinTech’ blog is all about how blockchain technology underpinning digital currencies such as Bitcoin can be used to innovate, improve, disrupt and re-invent processes in financial services.

The key concept is ‘decentralised applications’ – applications or systems which do not rely on a single entity to manage the substance of agreements between two or more transacting but otherwise independent counter parties, but rather which delegate such responsibility to the technology and the mathematically robust algorithms underpinning established and emerging digital currencies.

Decentralised applications have the potential to dramatically increase innovation, reduce costs, improve services, reduce risk, improve compliance and generally create a whole class of new economic opportunities for people who may not even be aware that these technologies are involved.

As it stands today, this vision is still only potential: it may not be realised.

The blog will attempt to communicate a shared understanding within the FinTech community of the benefits and opportunities  (or not) that Decentralised Applications could bring to Financial Services specifically, and to dependent industries, through innovative payment models.

The blog can be accessed here.

Decentralised Applications in FinTech

APIs, more APIs, and .. crypto-currencies

I recently attended #APIconUK, a conference on APIs organised by the folks at Programmable Web. This event was aimed at developers (bottom-up API development) rather than more traditional enterprise customers (top-down SOA-types), and as such was very poorly represented by enterprise-minded folks. Which, IMO, is a bit short-sighted.

The conference was good – a nice mix of hands on, technical and strategic presentations with plenty of time to chat to people between sessions.

Sadly I couldn’t make all the sessions, but key themes I picked up were:

  • Emphasis on treating APIs as a product
  • Computational APIs using Wolfram Alpha’s Mathematica
  • The rise of Linked Data
  • API Security
  • Payment APIs (Stripe)
  • Monetisation of APIs using crypto-currencies
  • Mobile developers & APIs

Adding all these together, what does it really mean?

  • APIs must be treated as first-class citizens with respect to technology management..inventoried/marketed, governed and supported in much the same way applications have been in the past.
  • It is possible to rapidly build useful services using sophisticated but usually not enterprise-standard tools like Mathematica, but to expose the end result as a RESTful API, which the enterprise IT teams can then re-implement in standard technologies. This allows consumers of the API to gain early benefit, and allow enterprise IT time to implement it in a sustainable,medium-term cost effective way.
  • Linked Data – the idea of attaching semantics to API information – is key for Machine Learning. APIs have the opportunity to become dynamic and self-forming when coupled with semantic information via Linked Data standards. Machine Learning is, in turn, key to automate or significantly improve processes that have relied on traditional BI reporting methods.
  • API security is a huge concern, but lots of vendors and solutions are beginning to appear in this space. In essence, it is quick and easy for anyone to create an API (just build a RESTful interface), but API management tools can help control who accesses that API, etc. It also imposes a level of governance to avoid proliferation of dubiously useful APIs.
  • Payment APIs are the next big thing. Stripe demonstrated a live build-it-from-scratch example of how to use their payment APIs, and it is remarkably simple. It doesn’t even need a client side SDK, as you can invoke the API via tools like CURL etc. An excellent example of how a simple API can hide the complexity of the back-end processing that must go on to make it appear simple..
  • Monetisation of APIs could be huge to incentivise the development of reusable services in direct response to demand. This is a significant topic, but essentially the current API model relies on many (internet-based) API providers ultimately making money from advertising, and not from the API itself. Introducing an API currency which is exchanged whenever external APIs are used, or external services use your API, is an intriguing concept, which may be useful even in a ‘traditional’ corporate environment, and would allow service providers to monetise their services directly without having to rely on ‘eyeball’ oriented revenue.
  • Mobile developers today still tend to build the back-end in a way that is highly optimised for the mobile application – in other words, any APIs built (RESTful or otherwise) tend to be designed for the specific needs of the mobile app, and not provided as a general service. Mobile developers have the opportunity to take the lead in ensuring that any mobile app results in the publishing of one or more enterprise-relevant services that other (mobile) app developers could use. Clearly this has an impact on how systems are designed and built, which is likely why the focus on mobile hasn’t produced good enterprise-relevant APIs.

Where does this leave the enterprise CTO? Here’s my take:

1) Mobile apps is where a lot of attention is these days..make sure every mobile project catalogs its data and makes an effort to publish reusable APIs. Do not let every mobile app have its own back-end server implementation, unless it is essentially just an orchestration layer.

2) Encourage developers to build and catalog APIs..even creating a simple, human-discoverable internal catalog like the one Programmable Web has would be a good start.

3) Understand your data from a business perspective, and document it using semantic web standards. This not only helps with IT planning, but is also directly usable in API and machine-learning initiatives, through standards like RDF and JSON-LD. Data architects are the best folks to tackle this.

4) Use API Management tools to help manage and control the creation and use of APIs.

5) Adopt principles like those proposed by the Reactive Development Movement to ensure that architectures behind APIs meet basic architectural standards, so they have some hope of coping with unplanned growth and utilisation.

6) Any app that does Payments should use a well-defined Payments API. It’s beyond the right time to develop internal Payment API standards for apps that have payment processing requirements..the increasing use of alternative currencies will expedite the need for this, as many traditional or legacy systems will not be able to cope with these currencies, so the API should hide this. Plus. it will help manage the transition from current state to target application landscape for payments-related applications. A model-driven approach to payments is key to this, especially as international payments standards take time to evolve.

7) APIs can enable innovative (read: non-standard) use of IT solutions, as long as the innovation can be encapsulated behind standard APIs. This gives the enterprise IT folks time to plan how to support the API, but still allow (limited) business adoption of the API for immediate business value.

With respect to how this all relates to SOA-type enterprise integration strategies, I’m still forming a view. Specifically, the internet itself does not have the concept of a ‘bus’. Someday it possibly will. But this is one space where the innovation still needs to come from enterprises, which still struggle with implementing successful SOA architectures that extend much beyond departmental boundaries.

Finally, the relationship between APIs and crypto-currencies is potentially so huge, that I will cover that another day..

APIs, more APIs, and .. crypto-currencies