Reading Time: 8 minutes

Previously, I wrote a blog post about IT Engineering here at MuleSoft and how we use MuleSoft products at MuleSoft. Inter-team communication is critical for us to complete projects and we decided to implement a Center for Enablement (C4E) approach internally. The MuleSoft customer success team offered to assist us in pursuing an evolved approach to developing MuleSoft applications for IT.

First off, what is a C4E? A C4E is an organizational practice to drive reuse and make development teams more agile.

latest report
Learn why we are the Leaders in API management and iPaaS
Read reports

Our goal in MuleSoft IT is to build something once following an API-led connectivity approach that allows us to reuse our assets, while securing the resources made available. The C4E approach is perfect for the MuleSoft IT team.

For successful product development and launch, certain assumptions and requirements must be satisfied.

  1. Every member involved in the process must have an effective role and be interested in producing a Proof of Concept (PoC), and, eventually, a production application from this process. Every contributor needs to have a role and they must know what is expected of them.
  2. Use domain driven design so that a high-level overview of all systems that are involved can be identified with a business context. (Example: context map drawing)c4e mulesoft
  3. The stakeholders for those systems must have an active interest in delivering a PoC and they must also be motivated to use C4E. If a contributor has a skill set that does not involve those systems, there is no need to include that person as a collaborator.  
  4. Every contributor must be included in the discovery process, this includes the business owners, architects, and engineers. This blog entry will focus on the discovery process and the importance of collaborating on the design phase.
  5. We emphasize API-first designed applications so if a contributor does not understand this approach, other members should bring them up to speed before digging discovery. Otherwise, critical time is lost explaining concepts instead of engaging in rapid discovery and development. This does not mean every member must be an expert. The C4E process is a great opportunity to add depth and experience to engineers and business owners. Less experienced users can focus on creating API fragments, data types, and libraries for MuleSoft’s Anypoint Exchange. More on Exchange later.  
  6. Use a PoC daily diary. For task identification, status, and deliverables. This is a great place to capture innovative ideas. (Example)c4e mulesoft
  7. Create a table for roles and assignments (Example)
  8. Identify use cases (Example) c4e mulesoft
  9. Lock down the project requirements for the first phase during the initial discovery project. Avoid scope creep at all costs! Every architect and engineer knows the risk that scope creep can cause. It is the primary reason for missing deadlines. Of course, critical features can be missed in discovery but call them what they are: misses. Sneaking them puts the entire PoC at risk of being delivered, so be realistic when setting expectations.

Once we begin discovery, we then identify all the systems involved. We confirm that every system has a business owner or technical resource for contributions. As the discovery evolves, we begin to discover when we can create a reusable resource or interface. If there is an opportunity to create something that other teams or developers can use, we flag that here.

As we identify the systems and the required resources, we determine the type of API we want to build. More specifically, will this resource provide specific access to another resource without additional complexity (a System API)? Will the resource/asset require some transformations, data filtering, merging, or other processing (Process API)? Or will the asset be a simple entry or exit point to third-party applications, a website, a mobile app, etc (Experience API)? More detailed specific explanations of these APIs can be found on MuleSoft’s documentation website.

What is important is to use this approach to develop a thorough application network that fosters reusable components that are governed and secure. During the process ideas on how to build better, more accessible applications arise. For example, during the process of our first C4E application, we found a better way to do item lookups. Don’t store those items in a file, a database, or even in the cache. Create a System API that is built for item lookup, then store those items in a file and make them accessible via an endpoint.

The best part is that those lists change, so when the list changes you can simply upload the new list to overwrite the old values. Also, many other applications require lookups. Use versioning to extend the API to allow for additional lookups.

That’s it for today! Keep an eye out for my next post with code examples for our simple lookup System API. And check out other blog posts on how we continue to use C4E to continually deliver on this and other projects.