A New Way to Think About Software Design
When I came to work with Mulesoft some 9 years ago, I soon discovered a new way to think about how to structure my software designs. I have long had a “nearly ready” pet project which was once written in Java, and later in Python, always with a weak commitment to the cloud for data management.
When I really began to understand the principle of Application Networks and API-led Connectivity, I saw that I could reconstitute my project in record time and already be way ahead of its current state. But you know, people at my new job began to find out who I was, so I didn’t get to do any “pet project” for a while. (I’m not sad about that.)
So what were we trying to say with this doctrine of API-Led connectivity?
The Magic of Application Networks and API-Led connectivity
The pace in enterprise technology is accelerating while we’re discussing this, and we must find new ways to get things done. There’s a lot of noise right now about how AI and co-pilots, and agents will give us great solutions, but — not yet.
So co-pilots for developers and managers, plus agents for business process designers are going to yield amazing results soon. But superstition, resistance, and human incompetence at adopting a transformative tool will make that “soon” be measured in years, not in quarterly results.
So we have to continue to do what we’ve always done. In enterprise IT that means finding ways to patch legacy systems together to get our people’s work done, and we must align ourselves with a strategy that avoids repetition of work.
If you could resolve this today for just one of Workday, Service Now, Salesforce, or SAP, don’t tell me the job of your IT team doesn’t get a whole lot easier.
The foundation of that new way is the Application Network. Here’s what it gives me. It’s a collection of executable IT assets that are discoverable by my developers, available for self-service, and each one presents an API to expose its functionality. It’s organized into three operational layers that separate concerns between data acquisition (System Layer), data reformulation into business concepts (Process Layer — tables and fields turn into customers and orders), and a layer that forges the information into a form required by its project (Experience Layer).
That’s a mouthful, but it can make a huge difference in the business of managing the demands on Enterprise IT development.
So consider the act of writing the part of a software project that is responsible for interacting with a structured database and retrieving data with a fairly predictable pattern. If I look at my developer team, I might well assign the task to any of them and get a reasonable result.
But haven’t I assigned this task to someone in the past — maybe more than once? Why am i doing this again?
This is part of the equation that Application Networks help us simplify. If I look at the business system (database, ERP, CRM, inventory manager) in question and find the person on my team who knows it the best, we can have them establish an API that interacts with the system but tames the complexity.
I don’t want to limit the complexity of what the consumers of the data can do, but access to that data should be simple and orderly. And the bigger win with an Application Network is that once that job has been done, it doesn’t have to be done again. The task of accessing a business system can be solved once, and then future projects can begin from that head start.
If you could resolve this today for just one of Workday, Service Now, Salesforce, or SAP, don’t tell me the job of your IT team doesn’t get a lot easier.
Enter the Model Network
So I’ve been telling this story for nearly 9 years, and there are literally companies all over the world that use this approach. But I’m always working with, and pointing to a piece of the solution. Rarely have I been able to help people see the whole thing in action.
So it occurred to me that what was needed is a nice model. A simple Model Network that would illustrate the various layers and observe their function, APIs that interact but that do not require outside resources, and at least a couple of APIs in each of the layers.
So this is the design. Each System layer API contains its own sample data and with samples to make the results interesting. There are four Process layer APIs. They deal with common business concepts for an airport such as flights, reservations, reservation and flight status.
One special API has a scheduler driven “event injector” that can alter the data held in the Application Network.
To avoid the dependency on an outside data sync, the various System layer APIs will utilize an Object Store to account for changes to the initial data embedded in those services. So at initialization of the service, a seed sample will be written to the Object Store and it will be maintained from there.
This is where the initial hack-a-thon work will occur. We can task teams to each create the infrastructure that supports updates and management of the network data. The best approach can be used to evolve the next version and expand the range of possible operations in the network.
How Can You Get Involved
The timeline for first workshop is not yet established, but early sign-up for an invitation to particate can be found here. Want to get in on the first use of the Model Network? Then sign up and join us!