Why you need both Systems Engineering and Agile principles - And an introduction to EPAM and the MACH Alliance

I am very concerned with eliminating silos in business automation, which is especially important for mutable businesses in a constant state of evolution (because silos introduce inefficiency and tend to reduce accountability, by increasing “finger pointing” and blame avoidance). We need to consider holistic processes delivering business outcomes, not “best practice” for individual sub-processes that can be rendered useless by inefficiency – or lack of effectiveness – elsewhere. Conventional DevOps eliminates silos in the application development process; but we must now address the possibility of DevOps becoming a silo itself. We must look at the bigger picture, for all stakeholders, which means considering a bigger feedback loop, from design thinking to business outcome.

There are related issues elsewhere in the business ecosystem. We don’t want to optimise a single compute platform as a silo, as an end in itself, we want to deliver business automation effectively, even if that means running a range of different compute platforms with different characteristics and running each workload on the most appropriate platform.

Two more silos that concern me are general business computing, with a “try it and see if it works” Agile attitude; and “systems engineering”, with a “get it right first time” and “don’t break what is working OK” attitude. In fact, we need both attitudes, used where they are appropriate for the delivery of the business outcome we need – Agile and prototyping for UX components and apps that change almost as a fashion thing; and Systems Engineering for architectures and frameworks that will last; and also for fundamental building-block components that will be orchestrated into evolving mutable business applications for years to come.

The trick is separating out the “essence” of your “essential” business automation which won’t change a lot unless, perhaps, you move into a new business (or which is associated with externally regulated components that simply can’t be changed unilaterally) from the stuff that must change, in order to attract new, and fickle, customers, in a changing business environment. Here, you may need advice and even “skills-transfer” mentoring.

A lot of this is cultural. I like PTC’s systems engineering tools, for example, but although they could be used to help deliver a robust “essential” business framework as a basis for agile change, I don’t think that they are often used that way, currently. PTC customers are largely from safety-critical, or aerospace, or defence, or other IoT-oriented engineering cultures.

I was talking about these and related issues with Matt Bradbeer, Client Partner at EPAM Systems and Board member and Treasurer of the MACH Alliance, and Natalie Gross, EPAM’s VP, Brand and Marketing, EMEA. EPAM Systems started at the end of the last century as an engineering-based business consulting, design and physical product development company and is now building on this with Agile, API-based, community-based delivery, as part of the MACH alliance. EPAM claims to offer both “enlightened builders” and “practical visionaries” – in other words, as I’d put it, rapid delivery of new software isn’t worth much unless it implements a real vision for a business outcome, and EPAM does both. What I like about Matt’s EPAM story is that he emphasises collaboration with EPAM’s clients and manages, as far as I can see, to combine Agile delivery with firm engineering principles.

In one case study, in which it facilitates a digital transformation, EPAM claims business outcomes (improved mobile app ratings; automated the customer digital checkout, increasing order automation from 5% to 85%; revenue growth as well as cost reduction) and better quality (fewer bugs), which are even more important than the claimed 30% increase year-over-year in digital product releases.

EPAM originally pointed me to the newly-formed MACH Alliance, “a group of independent tech vendors and System Integrators dedicated to advocating for open, best-of-breed technology ecosystems” – MACH stands for Microservices, API-first, Cloud-Native and Headless, which are the defining characteristics of next-generation business automation, according to EPAM.

The MACH alliance gives EPAM’s partners access to a larger ecosystem than can be maintained by a single vendor, and I would see potential for extending it with an OSS-style independent forum engaging small developers, customers and vendors – perhaps even including a marketplace for consultancy and components independent of the MACH Alliance vendors – although I am not sure how much of that last is on the Alliance roadmap just now, however.

EPAM sees MACH as a sign of increasing maturity in the marketplace. It provides its clients with an expanded set of technology choices, built on solid architectural principles. EPAM identifies 4 areas where, I think, MACH offers benefits:

1. You remain in control of your own roadmap and can move at your own velocity, largely because MACH is a multi-vendor platform based on multi-tenant cloud-native SaaS, and you can swap components for something better, whenever something better appears on the market. You are not tied to a single-vendor enhancement roadmap, reflecting the vendor’s own point of view.
2. MACH should both build revenue and reduce cost, while speeding up delivery. Productivity – business value – matters, even if many people concentrate on cost reduction, because it is easier to measure cost than value delivered. Improving profitability is the goal – although, considering the Future of Work (FoW), people are increasingly taking a wider view of “profitability”, across all stakeholders (not just shareholders), and including benefits to society.
3. “Rip and replace” of existing systems isn’t necessary – you can “encapsulate” existing functionality as microservices with an API and exploit your existing investment in the new MACH architecture.
4. MACH provides a pool of potential tech-savvy partners, who are technology-agnostic. You are not locked-in to a single vendor.

EPAM also points out, however, that it is vital that you review your own business operations and “business outcome” vision, and how the MACH stack might complement it – presumably in consultation with EPAM – before you fully embrace MACH (see Matt’s article “5 Things You Need to Know about MACH”. Successful implementation of MACH implies, EPAM believes, adoption of a product-led approach, with well-defined product ownership and cross-functional delivery teams.

Reviewing your business processes and outcomes before making changes is important whether or not you are looking at MACH, of course, but EPAM believes that “implementing a MACH framework can help your business get back to the basics of what technology was originally designed to do – make businesses more flexible, agile and faster”. Which sounds good to us, and although MACH isn’t the only way to achieve this, we think it is well worth looking at.