This blog post is an in depth look how to set non-functional requirements and achieving excellent deliveries from your integration suppliers. For those who wish to gain more knowledge about this and other areas of best-practises for integrations, please visit www.certifiedintegrator.com.
Apart from the everyday challenges of running agile deliveries from teams of external suppliers, making sure specified business requirements are met - handling integration deliveries has its own unique set of challenges. ach
Being a technically specific branch of IT, integration deliveries are of a more demanding nature in numerous aspects than other deliveries. In order to gain control over both functional and non-functional requirements there is a set of best-practises to understand and master.
When initiating an integration development there are the original business requirements and the functional requirements derived from them to start with. Depending on the nature of your business an integration development project may vary in performance or even be part of a sprint-based delivery, but the initial business requirements and connected functional requirements will be the same. Likewise, there is a set of non-functional requirements that needs to be addressed in all integration development projects, regardless of the nature of the overall business and functional requirements at hand.
Architecture, versioning and operability
Starting from a strategic approach when covering the various non-functional requirements that needs to be addressed, three distinct areas can be identified
- how to manage versioning
- shaping the overall architecture of the integration landscape to facilitate reuse
- the desired level of operability
Since these three areas has wide implications to integration development by affecting the design of individual integrations, achieving a unison approach will facilitate operations and maintenance of the entire integration landscape - so spending time to address them in depth is a good investment.
There are innumerable ways to build an architecture for an integration landscape. Aspects such as the basic systems involved, the nature of your business and legacy inherent from previous decisions on architecture in the overall information landscape, all sets unique limits and conditions for each integration landscape. Together these aspects makes it impossible to apply specific guidelines that are applicable for all integration landscapes, so focus needs to be on general guidelines that can be adopted to the situation at hand.
Identifying possible reuse
When designing or reviewing an integration landscape there needs to be a strategy to help maximize opportunities of reuse of integrations. Having a registry of all integrations, accompanied by some type of chart of the landscape as part of the integration landscape documentation, is vital in facilitating possible reuse, helping to identify candidates for reuse. Consider applying a layered architecture for APIs and integrations in the integration landscape, the most common type being a three-layered model based on a System-layer, a Process-layer and an Experience-layer.
Make sure that development will follow a structured versioning, being the fundament for lifecycle management of an integration landscape. By adapting the X.Y.Z versioning of integration changes as major, minor or patch, a lifecycle management strategy and corresponding lifecycle plans for each integration can be established. Minor and patch version above refers to non-contract breaking changes or updates, effectively leaving the integration fully operational for all concerned stakeholders without any separate changes of concerned systems in the integration. A major change would constitute a breaking change for the integration, requiring adaptations or changes to one or more of the concerned systems to uphold the set business requirements of the integration. Above mentioned lifecycle plans for the integrations will give opportunity to exercise governance for the entire integration landscape.
Operability - from good to excellent
Planning the desired level of operability for the integration landscape will give important input into the design of the individual integrations to be developed. Establishing the required logging, manual handling and monitoring will decide the level of operability that is possible to achieve for Operations and Support maintaining the integration landscapes functionality after deployment. What might appear as a pure operational issue is in fact a deeply embedded strategic issue since it’s difficult and expensive to add features for operability into the design of an integration after it’s initial development and deployment into production. Decisions about operability will also be a key factor for maintenance costs of the integration landscape.
A further look into operability can be found in the blog post Operability of end-to-end integrations
Summarizing strategic approaches
Make sure to address the strategic non-functional requirements
- establishing an architecture for the integration landscape
- structuring a lifecycle management based on versioning
- achieving excellent operability through proper error handling
Above measures have the same general and significant bearing on all integrations being designed and therefore needs consideration in advance.
With strategic approaches in place, it’s time to focus on tactical planning. Three areas of interest need to be addressed - standard patterns for the design, achieving scalability and covering essentials of security.
Transforming business requirements to a conceptual integration pattern
Going into the design phase, demand the use of the standard pattern for integrations from the integration teams, describing the integration according to a conceptual model were systems provides services, consumed as contracts, with one or more contracts constituting an integration. Consider how to define an integration, based on the business process. Start by identifying a logical function in the business process with a clearly defined input, process and output. By defining the integration based on the business process, it will be easier to connect ownership for the integration lifecycle management and operational costs to the stakeholders for the business process.
During the design phase, make sure that two areas are properly addressed and included into the integration design before the team starts development - capacity limits and scaling. Meet the business requirements by asserting that the integration performance reaches a desired level. Make sure that capacity limits are clearly defined, with business implications described when the limits are transgressed. By demanding possible scenarios for scaling the solution to be included in the design, possibilities for known future business scenarios can be decided upon, thereby not limiting future strategic choices from a scaling aspect.
Ensuring that the proper level of security is applied to the integration is imperative. Using the triad of Confidentiality, Integrity and Availability, balancing the three, make sure that business requirements for security are met in the design for the integration. Remember that choices of were in the OSI-model the security solution is applied can affect future development of the solution to meet new business needs.
To summarize this blog post, identifying how the above series of non-functional requirements for integration development apply to your integration projects and your business, is vital for achieving excellent deliveries. For those who wish to gain more knowledge about this and other areas of best-practises for integrations, please visit www.certifiedintegrator.com or register to our upcoming webinar or an upcoming one-day-course with the opportunity to be certified. https://www.certifiedintegrator.com/events.