Application networks and APIs are a key enabler of the composable enterprise, creating a more agile organization and allowing for rapid responses to changes in market conditions, technology disruption, and business demands.
Adopting an API-led approach in your composable enterprise allows each newly developed API to add incremental value to your overall application network and market place. It allows new capabilities and architectures to emerge over time, however, the fact that it emerges does not mean that there is no control over its growth. It can be a challenge to establish the initial vision for your organization’s application network — let’s dive into some of what those challenges are and how to overcome them by making a proper blueprint for your ideal state.
The challenge of visualizing your initial application network
Establishing the initial target state will allow acceleration for initiatives like defining the vision for your Anypoint Platform, defining a roadmap, and establishing KPIs and measurement plans.
MuleSoft’s Connectivity benchmark report found that the average enterprise has data in 900 different systems. To scale this many applications and systems can seem quite daunting. On top of this the following factors also come into play:
- Realize value quickly: Customers want to implement those first projects quickly.
- Migration: Most customers will want to consider migrating from previous integration stacks, even if this is not an immediate concern.
- Skillset: For some customers, there might not be an experienced MuleSoft delivery capability in-house.
When all of these factors are combined, it can be difficult to produce the initial target state for your organization. Here are three further examples of some challenges to clearly visualising your future state:
- Business-domain modeling
Challenge: To visualise the Process layer of your application network, understanding how to collapse similar services across multiple business domains is required.
Consideration: Aligning and collaborating with business stakeholders from the various business domains is a very valuable exercise early on in your organization’s journey. This initial interaction does not have to be an in-depth exercise and the initial blueprint does not have to be perfect, but taking input from the non-core technical and business teams will accelerate your organization’s success.
- Reuse
Challenge: When starting your API-led journey, it can be difficult to estimate the level of reuse you will be able to achieve.
Consideration: Considering the following will help to identify both the System and Process layer APIs:
- Systems of record
- Business data contexts they support
- The level of desired isolation
The initial target state should aim to be as accurate as possible, however, it is more important to visualize all of the APIs than to get perfect reuse estimates at this early stage.
- Processing model
Challenge: When creating your initial target state view, should batch and real-time processing be visualized on the same architecture diagram?
Consideration: The application network should represent the flow of information across your organization, regardless of processing model. If applicable for your organization (i.e. real-time and batch implementations need to be tuned differently due to batch sizes or other considerations) there could be two APIs that deal with the different processing models.
A methodical approach is required to produce the initial view of what “good” looks like for your organization.
Paving the way for a successful application network
The “plan for success” stage of your MuleSoft journey requires the actions listed in the image above. Once the target state application network has been established it serves as an input to most of the required actions in the technology delivery and organizational enablement streams. Below are a few examples:
- Define vision and roadmap:
The target state application network can inform which deployment topology should initially be used, but can also inform how this could be shifted to support long-term organizational goals, like moving to a cloud-based model as opposed to on-premises.
- Design an architecture and implementation plan:
The target state application network will directly influence how availability and reliability are designed into the platform architecture and also shape the implementation plan.
- Establish a C4E
Decisions on whether to adopt a centralized or federated C4E model will be supported by an overall understanding of the target state application network.
These three steps present a good opportunity to consider your own organization and reflect on how best to envisage the target state. The vision, roadmap, reference architecture, and implementation plan are all supported by this. Once developed and documented it accelerates and/or enhances the other core architectural artifacts for your organization.
Creating your target state application network
I would like to highlight two approaches for creating your initial view of what good looks like, from an application network perspective, for your organization.
Which of these you pick can be informed by your answers to the following questions:
- Business process landscape: How well understood and documented, at an organizational level, is your organization’s business processes and organizational structure?
- IT system landscape: How well understood and documented, at an organizational level, is your IT system landscape?
- Business and technology relationship: Is your organization’s implementation project made up of both IT and business stakeholders or is it heavily weighted towards one or the other stakeholder type?
Your organization’s C4E takes responsibility for considering, understanding, and ultimately documenting the target state application network. In undertaking this work and producing the target state blueprint to gain a better understanding of the various business processes, IT systems and both business and IT stakeholders will become embedded in the C4E.
Top-down approach
This approach is a good fit when there is a well-understood business process landscape, a reasonable or slightly less mature IT systems landscape and strong business representation in the overall implementation project team.
- Begin by plotting the business domains (i.e. Customer, Product, Order, etc.).
- Understand the domain language (i.e. CustomerName, CustName, CName, etc.).
- Consider the processes within these domains (i.e. Create Customer, Update Product, Create Order).
- Consider the interactions between these business domains (i.e. Order business process will have an interaction with Customer).
- Consider the client base of these business processes (i.e. Internal clients only, External only, Internal and External).
- Understand which IT systems are responsible for providing the information that drives these business processes.
- Consider the desired granularity of your application network according to availability, isolation, reuse, reliability, and commercial implication given your chosen Anypoint Platform deployment model.
An example, fine-grained decomposition could lead to identifying the following API subset, which would have become clear by approaching the application network with a top-down perspective:
- Experience APIs: Customer Mobile Experience API, Customer Web Experience API
- Process APIs: Get Customer Process API, Update Customer Process API
- System APIs: Retrieve Customer System API, Create Customer System API, Remove Customer System API, Update Customer System API
Bottom-up approach
This approach should be used when the business process landscape is not well understood/documented, the IT landscape is very well understood and the overall MuleSoft implementation project team has low levels of business representation.
The following approach can be used in this scenario:
- Begin by considering the IT systems (i.e. Customer Datastore).
- Understand the system’s data model, but do not consider tying the application network’s data models to those exposed by the underlying system. (i.e. RDMS Table structures and its representation of a business object, grouping of tables that make up a customer record).
- Reframe the underlying system data model to a higher level business domain language (i.e. Customer JSON, Customer XML).
- Engage the business teams that own the business capabilities to understand the required channels through which the business processes are made available (i.e. Internal web-based only, External mobile) and to validate your data model reframe.
- Consider the desired granularity of the data that the underlying system provides, its potential reuse and the commercial implications given your chosen deployment model.
- Consider the technical requirements for isolation, availability, reliability.
- Analyze organizational integration data flows and connections to understand who the clients of the identified domain languages are (i.e. Sales Team, Compliance Team).
This approach will lead to an application network which closely matches the example mentioned above (From the top-down approach).
Approach convergence
Regardless of the chosen approach, the resultant application network “blueprint” will be very similar. The benefits for the organization as whole will also be similar. Both approaches will:
- Create a strong technical AND business foundation for the technology delivery path.
- Engage and align a wider, cross-functional stakeholder community to create wider organizational visibility for your Anypoint Platform implementation effort.
- Establish foundational assets (C4E platform architecture, high-level business domain language placeholders/templates etc.) which will accelerate the growth of Anypoint Platform’s footprint in your organization.
But above all it will set a target state for your organization’s application network and provide focus for your C4E and other stakeholders to aim for as you take the first, exciting steps in your MuleSoft journey.
MuleSoft is here to help
Catalyst is MuleSoft’s unique approach which enables customers to achieve their outcomes while avoiding the common pitfalls. Our team is ready to work with you to lay the foundation for your organization’s long-term success.
Catalyst Launch will help your organization establish your initial plans for business alignment, project and platform strategies, and C4E amongst others. Refer to our Catalyst Knowledge Hub for more best practices or engage your customer success manager or wider account team for more information on the Catalyst Launch offering.
