How do you adapt to changing requirements and technologies in OOAD and distributed systems?

Consider a payment gateway (PG) with progressing increase in traffic. The original response metric designed was 1000 requests/second. Today, the PG requires to handle 100000 requests/second. Also, the business model has changed from a B2B to multiple B2C systems, with multiple vendors hosting their product/service as well, based on the unified payments model. Now there are more stakeholders, meaning improved authentication/authorization services. Adding components at the middleware level using web services will increase scalability & availability to handle more traffic. This also means iterative/stress testing/bug fixes. The beta release, sampled by all stakeholders, should extract many more issues, which need to be fixed.

Being experienced in modelling/design/architecture at an expert level, I have used MS Word, Visio, Rational Rose, MS PowerPoint, etc. depending on the problem at hand to give structure to the technical ideas in our collective heads. I have used IBM’s ClearQuest to document & create the right workflow design & change request impact analysis. Using UML with Visio (a highly versatile drawing tool), you can create most common diagrams to depict dependencies, architecture & state. The two main change requests in the PG can be depicted using state diagrams (higher traffic) & sequence diagrams (B2C business model). All team members should speak the same modelling techniques. Using web services is an ideal solution for the problem described.

Studying existing payment gateways, their business model, tech stack, middleware, change/issue log, release notes is the starting point of identifying patterns to apply to our payment gateway. This may reduce time taken to increase user base considerably, since we are replicating what has already been done but with some customizations. To change business model of being just B2B to B2C also requires a feasibility study, understanding the OOAD principles based on which this change can be built. Where a design pattern is applicable comes from our experience. Scaling an application/product needs strong planning & estimation skills, along with ability to empower your team to work as hard as they are capable of. Identify a common vision.

Once we identify the scope & model/design/architecture of the change requests, we can easily identify a set of technologies & tools that are compatible & work will each other well. We already know the existing technologies & tools that are being supported. To increase user traffic, the tech stack needs to be augmented with better run-time memory management architecture. An IDE if already being used, can be updated with technology updates & plugins. Tools like Bamboo, which take care of Application Lifecycle Management (ALM) are useful too. Any new technology, if being introduced, needs to be analyzed for fitment with existing technologies. A tool like Atlassian’s JIRA is platform independent & works with multitudes of tools.

If our development cycles are iterative, we are faster in responding to changing requirements. The idea is to have small duration scrums by splitting a large change request into smaller atomic ones, whose build process is incremental. Choosing the right tools itself will show the way with clarity. All stakeholder(s) will be on the same page as to what to expect when they see the agile story board. Not all agile practices may be necessary depending on the scatter effect of the change request. Most experienced architects, developers & testers will know how to iteratively expand the business logic, while keeping breakable components under control. This is why techniques like pair programming which bring about early bug detection is insightful.

OOAD has molted in so many ways from its origins. There used to be fewer languages, fewer approaches or tools to achieve the same goals a couple of decades ago. Information sharing arenas were lesser then. Today OOAD is the default choice for many a project manager who is managing a project & it may be a good choice because of how easily, maturely & seamlessly it can integrate with other prevalent/supportive tools & technologies. All available technical/abstract information on latest technologies help us process, learn & apply our strong fundamentals. Filtering technological information helps the developer choose/opt for tools with minimum learning curves. The advancement in technologies definitely helps improve the "people" & "process”.

Design wins over all processes, from my experience. During my stint at Dun & Bradstreet, I was asked to design a workflow framework. I was given full freedom to choose the tech that would work seamlessly with any persistence layer. Some people re-alignment going on, no senior manager was directly managing me then. I chose SQL & abstracted the middleware logic fully using queries. I designed the workflow in a span of two man-weeks, wrote a thin client & checked in the code. I fell sick & went on leave. My new boss said my code was useless. I challenged her if a tester took more than 3 hours to learn how to use my code using my thin client, I would give up the credit. My OOAD fundamentals won, I got 100% credit & a patent followed.