Executive Summary
Modern project management methodology and development techniques are able to mitigate the concern that business leaders have when they find it necessary to extend enterprise software functionality, or integrate an enterprise application with a new platform to handle niche functionality.
In this paper, we describe no technology, technique or pattern that is bleeding-edge, or in any way controversial. There’s no artificial intelligence, natural language processing or blockchain technology.
We are talking about software engineering 101: agile project management, prototyping, test automation, object-oriented programming, popular design patterns and microservices.
Everything in that list has been accepted best practice worldwide for more than a decade, and uses a platform-agnostic design pattern to deliver better results now, and as the industry evolves in the future.
Waterfall Delivery Method: Failed and Abandoned
Enterprise software delivery, as recently as 2010, still used a waterfall implementation methodology. Amongst Openlink client custom code, rarely was any solution using object-oriented programming practices. Duplicate code was rife. Every business analyst and developer with a hammer found a nail.
Project plans included a phase dedicated to detailed documentation of functional requirements. At the completion of the functional requirements, the delivery team started to work on the configuration that would satisfy the requirements.
For requirements that could not be resolved by configuration alone, a smaller team comprising a business analyst, technical analyst, with representation from the vendor and the client, would form. The team headcount could quickly exceed four.
For each of the custom solutions, a functional design was drafted. After the functional design was accepted by the client, the team would prepare a technical design. After the technical design was accepted, the solution build phase would begin. The first time the client saw the solution was only after the solution was complete. At that time, it was frequently handed back to the vendor because it failed to account for requirements, whether documented or undocumented. There might also be non-functional failures such as look-and-feel, scalability or performance problems. The design, build, delivery iteration would begin again.
Using a waterfall methodology, it was common for friction to develop amongst the team members when the front office had finished ‘their’ project deliverables, and the settlements, cash management, accounting and risk teams had only just been able to see the initial results of confirmations, settlements, pricing, and more. When you consider that the waterfall methodology for confirmations, accounting, and so on would commence only after the trade capture was complete, it is easy to see how implementations took years to complete.
This waterfall methodology has been retired at most organizations, although there are some enterprise software vendors that continue to plan their deliveries around the methodology. The primary reason the waterfall methodology has been largely abandoned is because of the high cost of repeated iterations.
Rapid Prototyping: Releasing Early, Releasing Often
Modern agile approaches to development often include rapid prototyping. The prototyping involves configuration and development of a solution, perhaps involving mock objects, to test some of the most difficult parts of the solution as early as possible. Prototyping need not involve code; it could involve pushing a dummy bond purchase or interest rate swap into the system to see the end-of-day pricing results using a flat yield curve.
It is easier to assess the feasibility of the design quickly, and to avoid a design path that results in failure. This approach often leads to ‘failing fast’ in design, and moving to an alternative solution. Compared to the waterfall approach, the feedback from users following a test-drive of a prototype is more detailed and more reliable that the feedback from a functional design document.
Users enjoy greater confidence in the solution. Stakeholders enjoy earlier feedback on project key performance indicators (KPI). The primary benefit of identifying a problem earlier in the development lifecycle is that it is faster and cheaper to address the deficiency.
Test-Driven Development: Delivering High Quality
Test-driven development (TDD) has been an accepted method for programming for nearly twenty years. Developers write unit tests to perform automated tests while they are building the solution. In fact, the preparation of the unit tests precedes the construction of the solution.
TDD leads to higher quality solutions, both in terms of delivery of the scope of a user’s requirements, and with fewer bugs. The solution typically carries less technical debt into production making the solution more agile and more easily able to accommodate entry into new asset classes, and the evolution of financial markets. Automated test suites can complete in under one second that which would take manual testers hours to complete. There is also evidence that manual testing suffers from deficiencies because the tedious repetition can induce apathy.
Developers enjoy the increased confidence they have when making changes to the code that they have not broken existing features. In fact, one of the greatest benefits, when there is a high degree of automated test coverage, is that a change to an existing solution can be assigned to a different developer. The new developer need not have a detailed understanding of the entire scope of hte solution before making a change because the automated unit tests will validate the new developer’s change has not broken existing functionality.
Object-Oriented Programming: Bridging Gaps Between Business and Technology
Object-oriented programming has been around for decades, and is not well-understood by business leaders. One way to think about it is that object-oriented code aligns more closely with the business requirements because the objects in the program represent business concepts. For example, there could be a Swap object, which has properties that describe the behavior of two (or more) SwapLegs.
A SwapLeg has properties that related to the leg of a swap, such as being fixed or floating, a currency or a yield basis. A Swap object has a counterparty (because the counterparty is not a property of the legs of the swap), a trade date, a USI (universal swap identifier) and much more.
The benefits of object-oriented programming are clear when thinking about communication between a business analyst and a technical analyst. The business analyst understands the functional requirements of financial markets, including what is a swap, and what it means for a swap to have legs.
The technical analyst is more likely to understand the database schema and API, which is a level of abstraction from which it is sometimes difficult to understand the underlying business requirements.
The conversation amongst the members of the team must meet on shared ground for a solution to be of high quality. Object-oriented programming allows the conversation to take place more easily because the business analyst is more likely to understand the Swap and SwapLeg abstraction in the code. At the same time, the developer is more likely to be able to impute the functional requirements from a glance at the object abstraction in the code.
When business analyst and technical analyst share the same language, it is easier to build and maintain high quality, robust solutions to the business problems. An additional benefit is that the objects end up being reused from one component to the next, dramatically reducing repetition in the code base, a cardinal sin.
Object-oriented programming is not sufficient to improve an organization’s solution set, but it is necessary.
System-Agnostic Tools: Enhancing Reusability
A seminal book was published more than 25 years ago called Design Patterns: Elements of Reusable Object–Oriented Software. It was written by a group of developers that have come to be known as the Gang of Four, with their own worldwide-accepted acronym GoF.
There are a lot of important development patterns described in the book, but one of the most important ones for developers working to extend enterprise applications is to develop system-agnostic tools. When extending the enterprise software, it is necessary to use the vendor’s API. But solutions that embed the vendor API deeply into the business object model constrain the reusability of the solution. When this anti-pattern is implemented in an object, it is referred to as ‘dirty’ object.
There are two important consequences of dirty objects that concern stakeholders: the solution is a lot harder to test in automated unit test suites, and the solution can not be easily used in conjunction with another platform. If the organization switches from one enterprise platform to another, the solution must be rewritten, basically from scratch. If the organization wants to reuse part of the solution in another existing platform, for example, a niche application that manages collateral, the solution can not be reused.
Development of custom code that abstracts the business requirements from the platform-specific API maximizes the ability to reuse the solution. Solutions should aim, as much as possible, to be system-agnostic tools.
Design Patterns: Improving Team Velocity
A lot of time can be lost during a project on team communication. New tools for software development can reduce the time lost in communication, and increase team velocity. Anything that helps eliminate unnecessary team communication, and switch from synchronous to asynchronous communication, helps efficiency.
The most common example of synchronous communication is the team meeting. Most project plans failed to account for the cost, in terms of person-hours, of a weekly, or even daily meeting cadence.
Design patterns such as Separation of Concerns and Service-Oriented Architecture simplify the distribution of work, and allow the project work to be distributed more efficiently amongst a team of specialists. These patterns are related to microservices, another widely accepted common development practice. Continuous integration, part of a DevOps culture, resolves code conflicts quickly, and reduces unnecessary communication between members of the team.
Together these development patterns and delivery approaches extend the potential velocity of the team by enabling scalability without compromising on quality.
Development Standards: Easing the Burden of Production Support
All too often, we see a failure for development teams to perform code reviews, which improves solution quality, and results. The addition of a review step is not the interference of a bureaucratic politburo. A reviewer catches insufficient test automation coverage, code repetition, inappropriate code abstraction, poor design pattern implementation, and more. The reviewer enjoys a broader view over the solution architecture and is in a position to promote improvements to the solution set.
Team Development: Modern Essential Skill Set
The foregoing uncontroversial advances to project delivery methodology, and software development techniques and patterns are made easier when the right skill sets are available.
Often, we find that problems are introduced when developers do not have sufficient knowledge of the business to design solutions that match tightly to the business problem being solved. This is not the fault of the developer alone, because the support from a business analyst often lacks technical skills necessary to communicate in a language most easily understood by the developer.
The developer typically speaks in a language of SQL queries, and works in an environment that is connected to the enterprise application via an API. When the business analyst communicates in a language too far divorced from the developer’s world of database tables and API, the outcome is most often going to include awkward solutions filled with technical debt that are difficult to support, and costly and risky to enhance in the future.
The most valuable member of the team is the developer deeply familiar with the business vernacular, or the business analyst with skills that traverse the database and API. These skills are difficult to identify in a single individual, but when encountered, lead to delivery velocity that matches or even exceeds a team of three narrowly-skilled business and technical analysts.
Managers would do well to promote a culture of continuous learning, that encourages business analysts to delve into the developer’s toolkit, and for technical analysts to have the time necessary to understand the operational requirements. Business analysts need not replace the technical analysts, and vice versa, but the team that includes staff with skills that traverse their comfortable domain perform at a higher level.
The skills take a long time to develop, so a more expedient path that delivers the value faster is to recruit, either as a member of the permanent staff, or as a contractor. Contract staff can be a better solution if the demand for the skills is temporary. But the market has spoken, and modern high-performing institutions demand these skills as part of the leadership of their critical strategic initiatives.
Additional Reading
- Gamma, Erich; Helm, Richard; Johnson, Ralph; Vlissides, John (1995). Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley.
- Brooks, Jr., F.P. The Mythical Man-Month: Essays on Software Engineering, 20th Anniversary Edition. Reading, MA: Addison-Wesley, 1995, 322 pages
- Brooks’s Law on Wikipedia
- Video: Microservices + Events + Docker = A Perfect Trio
