MuleSoft Catalyst
Centre 4 Enablement Playbook Establishing the Foundation.
Identify Assets to Be Created and Reused Across Initial Projects (cont…)
In this article I am going to look at some of the integration principles that will allow us to identify assets that we need to create in order to provide a firm foundation for the integration capability and allow us to start accelerating the development of API’s to serve the business.
My interpretation of these categories may not be what the Catalyst developers were expecting but are based on my practical experience of establishing a C4E and the surrounding aspects of the API capability. When looking at these areas I would encourage you to think about the three key foundations that I have used to assess the development of foundational assets
1) Security
2) Maintenance
3) Support
While looking at the value over time as suggested by the Catalyst Playbook may be a good way to prioritise the development of assets consideration of each assets contribution to the three areas above must always be kept in mind.
In my mind security is always at the top of the list when looking at the development of any API’s and this is even more important for the foundational assets which you are looking to be the most reusable API’s in your toolbox.
The reason that security is so important can be observed from a number of viewpoints.
The C4E should establish, at the beginning of its existence, a tight and effective relationship with the organisational security team. These are the lawmakers as far is security is concerned. In the same vein the Centre 4 Enablement are the police force of the API world as far as the organisation is concerned and need to enforce the laws made by the security team. With an ever-increasing threat from malicious attack it is important that all assets comply to the level of security defined for them.
Governance within the API capability is provided by the C4E governance processes. In the C4E that I work within we enforce security in both design and code reviews. Some of this can be automated but security still has to be enforced either manually or by automated processes that must be maintained over time.
Developers within the organisation may come from central IT functions, such as those working directly for the C4E or within the Central API Development team but, in addition, they may come from teams of consultants or third parties that are working directly with the business to develop API’s on their behalf. It is highly likely that these people are not familiar with the security requirements which must be enforced for each data classification within the business. Production of foundational assets, developed by the team that is in the best place to understand the security requirements, can lead to the reuse of these assets by other parties in order to accelerate development whilst still maintaining corporate security requirements.
This leads me on to the second point detailed above, maintenance. The relationship between the C4E and other parties such as IT Security must be established on an ongoing basis in order to keep security current and relevant. But, in addition to this, not on security but all other foundational and reusable assets should not be developed on a fire and forget basis but must be looked at as assets that need to be reviewed at a regular time interval. It’s a bit like building a car, you get a new car but then it requires regular servicing, this may be once every six months, once a year or on an extended basis dependent on which car you have. The same with API’s. Some may require reviewing every year and some may need more regular review and some may need revision based on an event that has occurred such as a security update. Be prepared for maintenance!
Of course, whatever you build and offer for reuse, or in some case insist on being reused, assets must be developed with the mindset that they will need to be supported. Perfection is the enemy of progress (famous quote alert — look it up 😊) so it is likely that circumstances may occur where a foundational asset may fail. Consideration of supportability at this stage may make your life very much easier down the road.
Now the MuleSoft Catalyst C4E playbook suggests a number of Integration Principles that should be considered when identifying foundational assets. Please remember that, at least in my view, these assets may be API’s, Fragments or documentation. Let’s examine each of the suggested principles and provide some real-world insight into how they may be relevant in this context. Note that some of the principles will overlap with the areas I have discussed above.
Reliability
Foundational assets, if they are identified correctly, will be used many times and, in fact, one of the main considerations for an asset being identified as foundational is precisely the fact that it will be used many times. If this is the case then the asset needs to be reliable, be seen to be of excellent quality and conform to all of the standards that have been set by the C4E.
Security
I have spoken at length above about this topic so I won’t go into any more detail here. As you will have gathered by now this is probably the top of my list of considerations.
Availability
There is little point in identifying and developing foundational and reusable assets if the IT and business users within the organisation don’t know where they can be found or how they can be reused. Availability and the publication of assets is vital to the success of the API capability across the organisation. We will address evangelisation of the C4E, API development capability and API reuse in a future article which will reinforce the message from previous articles, however, this is an important consideration when identifying the assets from the start. It’s worth remembering that foundational assets may include documentation including policies, procedures, standards etc so availability needs to be seen in the context of document storage and management as well as the exposure of API’s and API fragments which will be exposed through the MuleSoft AnyPoint Exchange.
Performance
When developing API assets which will be reused across the organisation, careful consideration must be given to the performance characteristics required by the organisation. Whereas some parts of the organisation may have very demanding performance profiles for their assets other parts of the organisation may be much less demanding. Where performance requirements may be more difficult to achieve these assets may take a lower priority that other assets as the overall benefits provided by lower performance assets may provide more overall benefit to the organisation. This will always be a balancing act as higher performance requirements may, but not necessarily, indicate a higher business importance. The message is don’t assume that you have to hit the higher performing asset demands without taking into account the overall business benefits. I’m not saying you shouldn’t prioritise these higher performance demands just don’t automatically put them at the top of the list for development.
Scalability
When architecting assets scalability should always be kept in mind. I have seen this as an issue and the last thing that anyone want to do is to have to revisit and rearchitect an asset because they never though it would have to deal with an increased volume of traffic or a higher SLA. Make scalability one of the factors that you consider for prioritising the development of assets. If the scale of the requirement is not known or is not well defined then this may not be a candidate for early development. In any case where reusable assets are to be prioritised and scheduled for development ensure that the design of the API is able to scale with no, or minimal, changes.
Supportability
As discussed above at some point in an assets life cycle there is a likelihood that something may go wrong. I have yet to see an aspect of IT that does not experience unexpected behaviour in its lifetime. When identifying assets in this context we need to consider how the C4E or the wider API delivery team will ensure that the asset is easily supportable but also consider the aspect that, if this an asset that will be reused, where of course we want as many of our API’s to be as reusable as possible, how can we ensure that, when our API is incorporated in another business process, we make it as easy to support from that perspective as well.
If you have ever worked in a support area, as I have, you will appreciate how important this is and how appreciative the support team will be when diagnosing faults.
Capacity
The amount of work that can be undertaken when developing reusable assets will need to be based on the capacity of the team. Sound obvious but this does have the impact that prioritisation does need to take place based on the factors described above. Basically, you have to do two things, work out what assets will give you the best ‘bang for the buck’ or if this is not sufficient find more bucks.
What I have found from experience is that there will immediately be some assets that you know you will need right form the beginning. The earlier you can identify, design and implement these the better things will be and the amount of rework will be reduced. If you have to wait for these then you are in the process of increasing technical debt from the beginning. Be careful not to get into a position where you are continually chasing technical debt.
Following the ‘obvious’ candidates there will be a grey area of assets that you definitely think you will need but can wait a bit longer. With these, project demands may play a role in establishing the priorities and beyond that other factors will come into play.
Of course, if demand drives then increasing the capacity to produce assets may be justified and additional resources can be drafted in but at some point a backlog will develop and it’s at that time you will need to consider all of the aspects I have discussed above.
It’s an interesting journey and one that I am happy to be undertaking. As they say it’s the journey that matters but you have to keep the destination in sight at least metaphorically if not in reality.
