By Paul Rohan Author: PSD2 in Plain English
Melvin Conway argued as early as 1967 that there is a relationship between the structure of an organisation and the design of that organisation’s products. This sociological observation has become known as “Conway’s Law”. In broad terms, products tend to “mirror” the architectures of the organisation in which they are developed. This occurs because an organisation can tend to search for solutions in a constrained environment. The environment is constrained by how the organisation is structured and governed. Organisations can have very established problem solving routines. Communication patterns between people within the organisation who are designing products follow quite rigid pathways. These environmental factors are very significant as they leave a very clear imprint on how products are architected.
Extensive research has shown that product architecture is an important predictor of product performance, product variety and process flexibility. If established firms in an industry are organised in a similar fashion, these factors can even influence the path of industry evolution. Most established banks are organised in a similar fashion. This organisational design is mirrored and imprinted in the design of electronic banking solutions for customers.
Academics have proven this relationship by looking at software products that fulfill the same function being developed by very different organisational forms. At one extreme, the academics have looked at commercial software firms, in which the organisational participants are “tightly-coupled”. This means that the software designers have very similar goals, structure and behavior. At the other extreme are open source software communities. These loose and informal organisations are much more “loosely-coupled” in comparison. The academic researchers have demonstrated that loosely-coupled organisations develop more “modular” designs than tightly-coupled organisations.
Modularity refers to the way that a product’s architecture is decomposed into different parts or modules. Modular designs are loosely-coupled in that changes made to one module have little impact on the others. When commercial firms like banks design software solutions for customers, the main aim is to develop a product that maximises performance (e.g., speed, scope etc.). The benefits of modularity, given the competitive context, tend not to be viewed as particularly significant. In open source projects, however, the benefits of modularity are greater. Without modularity, there is little hope that a distributed group of independent contributors can understand enough of a design to contribute to it, or develop new features and fix defects without affecting other parts of the system. Open source products need to be modular to attract a developer community and to facilitate the work of this community.
The intention of the XS2A articles of PSD2 is that API Developer communities will spring up around the legally mandated and externally published API suites offered by EU banks. Although not classic open source communities working on a single application, API Developer communities can tie numerous related customer solutions together in a highly modular arrangement.
The theory underlying XS2A is that these loosely-coupled communities will provide a highly modular environment for financial services customers to have more choices and extract much more value from their financial data. The new EU policy intention is that loosely-coupled communities of smaller providers will introduce innovation and new competition at a far faster face than tightly-coupled, monolithic banks. The smaller players have far narrower commercial goals and far simpler organisational structures, which reduces the sociological impact of Conway’s Law.
PSD2 plans to put bank data into a distinctly different realm of services development. The goals of tightly-coupled organisations such as banks are shared and explicit, while lightly-coupled organisations have goals that are diverse and implicit. Software designers in a bank are a closed membership, operating in a contracted basis. They respond to a formal authority, rather than the informal meritocracy in a loose developer community. Behaviour in a developer community emerges independently and is not centrally coordinated within a formal organisational structure.
We can consider how these tightly-coupled and loosely-coupled design environments could co-exist in the post-PSD2 world by examining the likely evolution of the SME enterprise software market. Tightly-coupled banking organisations, within the sociological environment predicted by Conway’s Law, currently tend to offer a very small range of highly packaged SME solutions. These packaged solutions are aimed at very broad strata of the marketplace. The packages contain multiple services. Banks will typically have an entry-level digital offering, aimed at sole traders and micro-businesses. There will also be a mid-range solution, aimed at the very wide group of SME businesses. Banks often offer a high-end corporate solution, for PLCs and multi-nationals. This product architecture often mirrors the organisational structure i.e. a bank’s Micro-Business Department has their multi-purpose package to sell, the SME Department has their multi-purpose package to sell and the Corporate Banking Department has their multi-purpose package to sell.
We can contrast the tightly-coupled banks with loosely-coupled organisations of small players that cluster together through APIs to meet the enterprise software needs of SMEs. For example, if an SME buys a Cloud Accounting solution such as Xero, Sage One, Surf Accounts or Big Red Cloud, they are positioning themselves to smoothly add third-party add-on modules as their business expands. As the SME becomes more complex, opportunities will be there to add-on modules such as CRM, eCommerce, Expense Management, Inventory Management, Payments, Payroll and Point of Sale solutions that use the published APIs of the Accounting solution. API is a protocol that enables fields of data in each module to be matched, letting data flow between the loosely coupled system. If one of the add-on solution providers falls behind in quality or price, the overall value of the environment to the SME is reduced marginally. A replacement add-on function can be inserted without major disruption. In contrast, if an SME relies on a single multi-functional enterprise solution from a tightly coupled commercial organisation, there is a lot more at stake if the solution falls behind on quality or price. The loosely coupled environment also allows a business to only source the functions that match their business model e.g. a B2B SME doesn’t need Point of Sale, a Services SME doesn’t need Inventory Management etc.
The chosen Regulatory Technical Standards to ensure a streamlined implementation of PSD2 across the EU may not be fully in place until late 2018 or even early 2019. However, this effectively marks the final deadline when EU banks must have a basic API strategy and a tested API Suite in order to be compliant with EU law.
PSD2 will empower nimble third-party service providers, loosely coupled together through APIs in development communities, to access bank data in order to further strengthen their propositions. Perhaps tightly-coupled banks cannot beat them and must join them? Banks themselves can access valuable data through published APIs from third-party Accounting, CRM, eCommerce, Expense Management, Inventory Management, Payments, Payroll and Point of Sale solutions. This approach would make the value propositions from banks far less monolithic and far more modular. In very crude terms, EU banks could use PSD2 law to help them beat Conway’s Law.
Paul Rohan explains PSD2 and the Future of Banking https://t.co/mJqjuzDvSL
— Paul Rohan (@paulrohan) February 6, 2017