The record company Monster Records & Associates (referred to as MRA) has struggled to cope with the changes in the music industry. With new leadership at MRA, the way the company is perceived is changing. Record companies, including MRA are no longer in the business of running recording studios, CDs and vinyl presses, or helping artists become media friendly. They are digital companies and their assets are largely data. Today, the majority of MRA's revenue comes directly through downloads and streaming, both directly from MRA and via Amazon, Spotify, and other services. Significant revenue also comes in from other means such as licensing music to television, films, podcasts, radio, and advertising.

Modern recording deals with artists look more like agreements to lease the right to use a recording or composition. This at least in part has come from the fact an...

The existing landscape is an aging set of on-premises solutions and makes heavy use of human processes. To establish some direction, it is obviously necessary to both understand the existing and desired IT Landscapes.

The core components of the existing landscape are made up as follows:

All the financial processes are realized by an on-premises ERP fronted by services deployed on top of Oracle SOA Suite. The data to be consumed by ERP comes through several approaches:

• Keying or rekeying of data
• Manually imported from spreadsheets and CSV files, driven through the UI
• A number of Oracle SOA Suite services receiving SOAP/WSDL calls from other systems within the organization or exposed by VPN...

The following diagram shows the functional entity relationships within MRA:

The following table provides further elaboration on the meaning of the entities in the preceding diagram:

With the IT landscape outlined, the goals wanted in broad terms is that it would be normal to drill into identifying the value propositions of APIs on the different areas, qualifying success criteria, and so on. With this, the domain partitions would be further analyzed to ensure that they're well understood.

However, this book isn't aiming to be a benchmark on analysis and design, but it aims to draw out the issues relating to APIs and the adoption of a suitable platform.

To meet these identified goals several APIs have been identified. The next section works through what these APIs are.

To move forward, MRA determined that they need to adopt some strategic approaches and design models. In doing this, MRA are trying to ensure that industry good practices get incorporated into the future IT landscape.

To this end, MRA looked at several different reference architectures such as IT Strategies from Oracle and Open Modern Software Architecture Project (http://OMESA.io). As OMESA reflects the current thinking and is relatively lightweight, it recognizes the fact that there is an existing IT environment that needs to be accommodated. OMESA is also vendor agnostic.

Open Modern Software Architecture Project (http://OMESA...

With an understanding of the existing landscape and where we need to get to go, working with an approach of a minimal viable product and API 1^st in terms of solution for MRA, we can sketch out a roadmap which the following chapters will follow, as shown in the following diagram:

Details of this lifecycle will become clearer in the following chapters. The following table provides a brief summary of each phase shown in the preceding diagram:

In this chapter, we described the situation our fictitious company MRA sees itself in, which isn't too different from that of many real businesses. We described where MRA wishes to get to, including the capabilities the APIs will need to help deliver. We also took a good look at OMESA as an architectural framework and some of the design concepts techniques that lend themselves to the approaches we will adopt. We also introduced you to certain terminology and ideas that we will explore later in the book. In addition to this, we looked at a roadmap for developing capabilities to take MRA forward. We then ended the chapter with certain high-level API requirements and some steps of progress that need to be taken.

In the next chapter, we will explore the API 1^st approach in depth along with the means by which we can design and communicate the API definitions. The value...