I've heard that Mechanical is like a next generation Pivotal Labs. What's different?
At Pivotal, we built systems for and with clients, and we do that at Mechanical Orchard as well. The difference at Mechanical is that we also specialize in cloud operations and can run these applications on behalf of clients.
So is the operations offering from Mechanical what we've traditionally known as "managed services"?
Yes and no. We don't want to take over your data center, or simply run your applications for less. We run only what we build, or in some cases what we co-develop with our clients. This ensures that we are operating software at the highest levels of reliability and performance, and allows us to form a "closed loop" around our Build and Run offerings, with each service informing and optimizing the other.
How do your managed services differ from what the big cloud providers already offer?
The primary difference is that we’re operating and developing software at the same time, often paired with our clients’ developers, who are learning the latest techniques and technologies from us. The major cloud providers offer many automated services to optimize your cloud usage, and we’ll plug into those capabilities too.
So is the operations offering from Mechanical what we've traditionally known as "managed services"?
Yes and no. We don't want to take over your data center, or simply run your applications for less. We run only what we build, or in some cases what we co-develop with our clients. This ensures that we are operating software at the highest levels of reliability and performance, and allows us to form a "closed loop" around our Build and Run offerings, with each service informing and optimizing the other.
Are you still agile?
Definitely. We still test-drive all our code, we pair-program, and we refactor constantly. Our Run team applies agile techniques just like our Build team, but also benefits from the years we spent building and operating cloud infrastructure at Pivotal, with all the attendant lessons learned in DevOps and Site Reliability Engineering.
What's all this about "digital twins" and "Dyson spheres"?
It's how we describe some of what we do in our distinctive approach to legacy modernization. These are colorful terms, obviously, but we're quite serious about how we approach it. We expect it to be a huge part of our business.
How, specifically, is your approach to legacy displacement different?
Most attempts at building the next generation of critical legacy systems attempt to mix new requirements with some degree of feature parity. This can lead to excessive scope, requirements that do not easily coexist, and abrupt organizational change. In contrast, we build an exact replica of the existing system (a "digital twin") first: bit-for-bit, pixel-for-pixel, and bug-for-bug.
To provide a little more detail, our approach to modernizing legacy systems is to draw a clear boundary around the target system (a “Dyson sphere”), capture all data that crosses that boundary, and use that data to construct a comprehensive test suite. This test suite asserts the behavior of the target system, enabling us to test drive our way toward an exact replica (a “digital twin”).
So wait, you want to build a bit-for-bit twin of my legacy system? Our organization wants to move well beyond that legacy system with a fully reinvented set of workflows and features. Why do I want a twin of the old thing?
Once we have deployed the new system and decommissioned the old - with very little impact on the business - we can safely and efficiently embark on an incremental evolution of the system toward its next generation (and fix the bugs). In other words, a digital twin is step one, but it’s a crucial step toward a holistic modernization.
Doesn't most of the industry regard rewriting software as an anti-pattern?
That's the received wisdom. However, we're quite confident in our approach. We don't rely on user requirements to build the digital twin, and we don't even need the code in many cases. We use a data-driven methodology, and we bring the techniques, technology and experience to do it correctly.
Why replace legacy systems at all?
To start with, because they're difficult, and sometimes impossible, to change. For example, for one F500 client, we've just replicated the core functionality of a mission critical system for which there was no access to the source code at all. Oftentimes, the original authors of a system have left the company or retired. There may be a vast estate of legacy code with just a few remaining programmers who know how to maintain or change it, and efforts to forestall their inevitable departure can only succeed for so long. The clock ticks.
Another issue is aging or obsolete hardware and software. Many times these systems are no longer supported commercially, which can pose serious security risks.
Either way, perhaps the greatest driver is the opportunity cost. Most organizations want nothing more than to be bold with their technology investments, and move quickly into the future with nimble, resilient businesses. Legacy systems retard that kind of innovation.
Do you still build greenfield systems?
Absolutely. We cheerfully use our decades of experience with lean product, user-centered design, agile programming, and modern cloud operations to build and run new software systems for, and with, our clients.
