Performance or scalability issues Archives

Modernization 2.0: legacy to microservices transformation

Migrating to a cloud-native architecture is one of the most powerful ways to improve business agility. The modern cloud delivers virtually unlimited, on-demand compute power, enabling platforms to scale instantly to meet demand. It’s no surprise that 94% of companies worldwide already use cloud computing in some capacity, and 97% of IT leaders plan to expand their cloud systems in the next few years (source).

Yet many enterprises remain constrained by legacy, monolithic applications. These systems hold critical business logic but act as bottlenecks to digital transformation. Insurance applications, banking platforms, and other unique software systems have been built over the course of decades in languages like PowerBuilder, EGL, and Smalltalk, among others. These types of systems require a flexible, customizable, scalable, and agile modernization process that can be easily jump-started to deliver incremental results.

But how can you untangle a complex monolith without disrupting stable functionality and critical business operations? After all, carving out pieces of a monolithic system is a manual, labor-intensive, and time-consuming process. To move forward in today’s climate, organizations need a controlled, automated approach that ensures critical functions can be safely modernized, tested, and deployed in a timely manner.

Architectural breakthrough: microservices + micro-frontends

The optimal solution lies in a more modern architecture built on microservices and micro-frontends. Microservices are a web of independent, modular components that can be scaled, updated, and reused individually. Micro-frontends are user-facing components that can operate either independently or as a cohesive whole.

Modernizing the front end is just as important as modernizing straight business logic. Forrester Research finds that companies investing in UI/UX design see a $100 return for every $1 spent. Outdated interfaces remain one of the most immediate barriers for legacy applications, and micro-frontends directly address this need.

Synchrony Systems’ Modernization Lifecycle Platform (MLP) comes equipped with end-to-end automation for extracting “subsets” of business logic and user interface, and transforming them into reusable components for microservices and micro-frontends. This enables organizations to modernize their monolithic legacy applications into a hyperscale cloud architecture. By focusing on the high-value business functionality first, Synchrony helps accelerate modernization timelines so enterprises can deploy and test migrated functions and complete features continuously in months instead of years.

The illustration below shows how MLP orchestrates a modernization solution from a PowerBuilder monolithic architecture to a target microarchitecture with a TypedScript/React frontend and a TypedScript/Node.js backend as the target programming languages. (click image to enlarge)

How monoliths become microservices and micro-frontends

Rather than migrating monolithic legacy codebases wholesale or “as-is,” Synchrony offers a technology-assisted reengineering process and workflow that is iterative, incremental, and analysis-driven.

Analytics and application rationalization

First, an exhaustive analytical inspection of your legacy application is performed using modernization technology purpose-built to identify and extract high-value business scenarios and their execution paths. This analysis produces targeted, self-contained components (a.k.a. “subsets”) for every identified business scenario embedded inside each monolithic codebase. This extraction acts as the foundation for exposing the hidden application “component vocabulary” in terms of application layers, subsystems, and business functions. Powered by the newly exposed knowledge of your system, the extracted component architecture becomes the stepping stone that drives continuous and incremental modernization toward the target cloud component architecture.

Target architecture metadata harness

The new application component architecture is the first representation and visualization of the formerly monolithic application’s structural decomposition into a granular micro-frontend/microservice layer. The component model is used for generating the required metadata that drives the execution of every modernization service agent, such as: a) data access generation; b) business objects generation; and c) UI facelift generation into a reactive frontend. This is where client-specific requirements are also incorporated to align with IT’s model target architecture.

Fine-tuning the transformation engine

The breakdown of subsets further undergoes an iterative process that identifies micro-frontends, microservices, and common layers used by both. An interactive process identifies UI/UX requirements and service layer requirements (typically slated for data access) to produce highly granular, reusable, and scalable components on the target. The process results in custom-tailored code refactoring, transformation, and generation, rules knowledgebases (KBs) for target business services, and facelift rules for a modern, reactive target web frontend.

Orchestrating modernization workflows

The analytics, metadata harness, and fine-tuned transformation knowledgebase are all assembled into custom-tailored workflows. When executed end-to-end, they produce the desired target architecture, consisting of hundreds and often thousands of structural (repositories) and microarchitectural (microservices and micro-frontends) components. Workflows can be invoked on demand by users or triggered by specific events, such as commits to newly generated code or updates to the metadata harness or KB. The holistic integration of code, tools, and processes ensures that the modernization project runs efficiently and at scale.

Continuous modernization

All units of execution inside a workflow, known as “autoflows,” can be thought of as pipelines of pipelines that enable continuous execution of the entire modernization lifecycle. The original monolithic application architecture is incrementally decomposed into independent, atomic, and stateless microservices and self-contained, reusable micro-frontends, ready for deployment into IT-specific cloud environments. The result is a transformed application with cloud-native architecture and modern UI/UX, preserving the original business logic and retaining 100% functional equivalence.

The illustration below shows an end-to-end customized MLP modernization workflow for monolithic client/server desktop applications. (click image to enlarge)

Why modernizing to microservices and micro-frontends improves speed and agility

Customers can continuously extract high-value functionality and features from their legacy applications at their own pace and timeframe, until everything is modernized.
Eliminating dead code and breaking the monolithic functionality into a web of independent microarchitecture components eliminates technical debt and fosters technological agility.
Legacy applications get fully transformed into modern target architectures, unlike the like-for-like, “as-is” transformations that preserve the legacy architectural semantics, making it hard to be agile and scalable on modern target platforms.
Microservices and micro-frontends are delivered incrementally as early milestones for customers to test and deploy into production piecemeal, rather than waiting for the entire application to be modernized.
Built for flexibility and adaptation, Synchrony’s modernization platform conforms to the customer’s specific target architecture, tooling, and requirements (e.g., RESTful, Kubernetes, cloud infrastructure, API gateway, widget libraries, data access harnesses, etc.) rather than dictating a standardized solution.

Real-world transformation: from monoliths to microarchitectures

Modernizing monolithic application architectures into microarchitectures enables companies to untangle decades of core domain functionality and extract it into highly reusable components. Synchrony has helped dozens of teams extract and transform critical domain functionality and UI from their legacy client/server or host/mainframe monolithic architectures into reusable target microarchitectures.

PowerBuilder

A PowerBuilder client/server application subset (after removing dead code and selecting the initial set of high-value components) with a traditional monolithic architecture:

Windows → 323
Data Windows → 1,908
Lines of Code (LOC) → 416K

Yields the following cloud microarchitecture:

Micro-frontends → 47
Microservices → 488
Repositories → 1,650

Would you like to learn how this could be applied to your in-house legacy applications?

Contact us to meet with our senior modernization specialists for an in-depth conversation and consultation about the target architecture options your in-house portfolio of legacy applications can take.

Microarchitecture in legacy application modernization FAQ

This FAQ addresses common questions about our technology, drawing from our expertise in modernization. Whether you’re a developer, architect, or CTO, these insights can help you understand how to revitalize your tech stack without disrupting operations.

What is microservices extraction in legacy application modernization?

Synchrony Systems’ Microservices Extraction technology is an automated tool that untangles complex legacy monoliths and converts them into a network of reusable microservices and microfrontends. It focuses on extracting subsets of business logic and user interfaces from languages such as PowerBuilder, EGL, and Smalltalk. This process creates independent, modular components that can be scaled, updated, and deployed individually in a cloud-native environment, such as TypeScript/React for frontends and TypeScript/Node.js for backends.

Why should enterprises modernize legacy applications into microarchitectures?

Legacy applications are, by definition, outdated. They are built on aging infrastructure and rely on a talent pool nearing retirement to keep running. These systems inherently limit scalability, agility, and innovation. By modernizing to microservices and micro-frontends, organizations can leverage the cloud’s on-demand compute power, enabling instant scaling to meet demand. This shift eliminates technical debt, fosters technological agility, and allows for incremental improvements without a full overhaul.

How does Synchrony Systems’ platform differ from traditional modernization approaches?

Traditional methods often involve manual, labor-intensive processes or “as-is” migrations that preserve outdated semantics, making it hard to achieve true agility. Synchrony’s platform uses end-to-end automation for an iterative, incremental, analysis-driven reengineering process. It avoids wholesale migrations by focusing on high-value business scenarios first, delivering functional equivalents in months rather than years. The result is a hyperscale cloud architecture tailored to your specific requirements, including RESTful services, Kubernetes, and custom API gateways.

What are microservices and micro-frontends, and why are they important?

Microservices are independent, modular backend components that handle specific business functions, allowing them to be scaled, updated, or reused without affecting the entire system. Microfrontends are user-facing UI components that can operate standalone or integrate seamlessly. Together, they create a flexible “web” of components that improve speed, reusability, and overall application performance.

What is Synchrony’s step-by-step process for microservices extraction?

The process is built into the Modernization Lifecycle Platform (MLP) and includes several key phases:

Analytics and application rationalization: An exhaustive analysis identifies high-value business scenarios and extracts self-contained components, revealing the application’s hidden “component vocabulary” across layers, subsystems, and functions.
Target architecture metadata harness: This generates metadata to drive modernization agents, incorporating client-specific requirements for data access, business objects, and reactive UI generation.
Fine-tuning the transformation engine: Subsets are broken down into granular micro-frontends and microservices. An interactive process refines UI/UX and service layer needs, creating custom refactoring rules and knowledgebases.
Orchestrating modernization workflows: Analytics, metadata, and transformation rules are assembled into custom workflows that produce structural repositories and microarchitectural components. These can be triggered on demand or by events like code commits.
Continuous modernization: Workflows run as “autoflows” (pipelines of pipelines), incrementally decomposing the monolith into atomic, stateless components ready for cloud deployment. The final output is a fully transformed application that preserves business logic and is 100% functionally equivalent.

If the modernization process is automated, how does it ensure safety?

Synchrony’s MLP emphasizes controlled automation to avoid disrupting stable functionality. It uses purpose-built technology for inspection, extraction, and transformation, ensuring critical functions are modernized, tested, and deployed safely and accurately. Automation handles the heavy lifting, but the process includes iterative fine-tuning and interactive elements to incorporate your team’s input throughout the modernization process, minimizing risks and maintaining operational continuity.

Can modernization be done incrementally without a big-bang approach?

Absolutely. MLP enables continuous extraction of high-value functionality at your own pace. Microservices and microfrontends are delivered as early milestones, enabling testing and piecemeal production deployment. This eliminates the need to wait for the entire application to be modernized, reducing downtime and accelerating timelines from years to months.

What benefits does this technology provide in terms of speed and agility?

Reduced technical debt: Breaks down monoliths into independent components, eliminating dead code and enabling easier updates.
Improved scalability and flexibility: Components conform to your target architecture (e.g., cloud infrastructure, widget libraries), fostering reuse across teams.
Faster time-to-market: Incremental deployments mean quicker value realization from high-priority features.
Improved UI/UX: Transforms outdated interfaces into modern, reactive frontends, enhancing user experience and ROI.
Full transformation: Unlike “as-is” methods, it delivers a truly cloud-native architecture for long-term agility.

Which legacy languages and systems does Synchrony support?

MLP is designed for a variety of legacy systems, including client/server desktop applications written in languages such as PowerBuilder, EGL, Smalltalk, VisualGen, COBOL, and more. It’s flexible and customizable, able to handle unique monolithic architectures across insurance, banking, and other industries.

How can I get started with Synchrony Systems’ Microservices Extraction technology?

10 app modernization mistakes to avoid

Modernization promises the benefits of a modern, cloud-based tech stack, including remaining competitive, innovating quickly, supporting mobile, and reducing security risks. Yet app modernization initiatives are fraught with complexity. Sadly, over 75% of modernization projects fail, according to multiple studies conducted on mainframe and application modernizations.

Executives, architects, and technical teams must be aware of the warning signs that a modernization project is starting to go sideways. Here are ten app modernization mistakes to avoid to increase your chances of a successful initiative.

1. Shortcutting modernization readiness homework

The devil is in the details regarding app modernization. While limited documentation, technology expertise, or even historical context for changes in the legacy application are common problems, the more significant risk with application modernizations is the inability to scope the project properly. Making assumptions rather than conducting an actual modernization readiness assessment often leads to underestimating the size and complexity of the technical debt and, hence, the overall effort required for the modernization. As a result, the project is set up for failure before it even begins.

2. Treating application modernization like a typical software development project

Nothing could be further from the truth. These applications typically run critical parts of the business, and modernization efforts must be managed in parallel to support the day-to-day business operations. Unlike the typical greenfield development lifecycle, where many engineers make many small incremental changes to one program or function at a time, a modernization project makes wholesale changes to millions of lines of code simultaneously and repeatedly. Planning a modernization project like a greenfield project is a huge mistake.

3. Assuming a good migration tool is the only key to a successful modernization

Machine-driven migration tools are crucial to modernization projects, but they are just a part of a successful modernization project. These tools are akin to best-of-breed compilers and their role in greenfield application development. Yes, we need a good compiler, but without the well-established best practices of DevOps, no compiler by itself can ensure the successful completion of a software development project. So yes, we need good migration tools. Still, they must be integrated into holistic modernization processes that help bring migrated code to production quality, see it through to production release, and retire the legacy application.

4. Overreliance on code migration tools

Piggybacking on the above, teams always investigate the available code migration tools. Automated code transformation takes care of only a third of the work in a complex modernization project with many moving parts and stakeholders. Without integration of migration tools with CI/CD build pipelines, defect management, test management, code synchronization between parallel development and migration tracks, project management, analytics, reporting, and more, it will be impossible to successfully manage such complex projects and see them through to completion.

5. Underestimating the difficulty of modernizing a moving target

Applications that require modernization are often live/running systems that undergo development – bug fixes, enhancements, feature requests, integrations, etc. – based on the needs of the business. Halting development or freezing the application code isn’t feasible, especially when today’s modernization projects average sixteen to twenty-four months or more. The biggest Achilles heel of modernization is the inability to keep up with the rate of change happening to the application while it’s undergoing modernization.

6. Trying to modernize everything at the same time

The end-state is clear. A modernized application will use modern technology, be cloud- and mobile-ready, and embrace current UI/UX best practices. However, the system to be modernized is typically monolithic and was developed with what today would be considered obsolete software development practices. Trying to tackle this challenge all at once significantly increases the risk of failure as it drives up the demand on resources, time, and costs and ultimately erodes the trust of senior executives and project sponsors. Instead, develop a minimal viable product, or MVP, modernization roadmap. An incremental approach will still result in wholesale modernization, but it’s being done piecemeal. This incremental approach makes modernization more manageable, trackable, and measurable and de-risks the entire project.

7. Not having project visibility

Large-scale, complex application modernizations often require internal resources and several external partners with specific migration expertise. The work is usually managed via spreadsheets, Gantt charts, project management or collaboration tools, and constant status calls. Outside the project management activity, the modernization work occurs in various development environments siloed to the teams working in their particular areas. So, despite everyone’s best intentions, modernizations are fraught with miscommunication, delays, and project bloat, costing more money and time. These challenges must be acknowledged and addressed as part of the overall modernization strategy and, where possible, solved with modernization lifecycle management solutions.

8. Tracking the wrong modernization success metrics

Some metrics show project progress but may not be success indicators. For example, measuring the number of migrated lines of code or how much code compiles doesn’t mean the code is actually running. Additional metrics that track the progress of the modernization are how much code is executing or code coverage, the impact of a new version of a code drop, and the overall project trends.

9. Claiming victory too early

Once the modernized application is in production, it’s tempting to sunset the legacy application as quickly as possible. After all, maintaining legacy applications takes resources that could be deployed on other strategic initiatives. However, the modernized application must be exercised in production for enough time to ensure that the migrated code operates as expected in the day-to-day operations. Sunsetting the application too early prevents a quick remigration using updated automation rules and instead forces a development team to prioritize, schedule, and address these issues manually during a development sprint.

10. Ignoring employee impact

Modernization is more than technology. It often triggers a fundamental shift in development processes and team organization, with many companies adopting DevOps principles, cloud deployment, and modern development best practices. It’s a sea change for the developers who are maintaining the legacy application. Therefore, it is essential to consider and plan for the impact on employees post-modernization.

About Synchrony Systems and our app modernization technology

We have reimagined how application modernizations are executed. Our technology has helped some of the world’s largest brands with assessments, readiness analyses, roadmaps, application migrations, and application transformations. Contact us today to learn how we can help you.

Why modernize EGL applications?

Enterprise Generation Language (EGL) was a powerful tool in its time, but the technological landscape has evolved significantly. Modernizing EGL applications is crucial for businesses to remain competitive and agile.

Here are the primary reasons to modernize:

1. Improve user experience:

Outdated interfaces: EGL applications often have dated user interfaces that are not intuitive or mobile-friendly.
Enhanced user interaction: Modernization can create engaging, responsive interfaces that meet contemporary user expectations.

2. Increase efficiency and productivity:

Legacy systems bottlenecks: EGL applications might have performance limitations or scalability issues.
Automation: Modernizing can incorporate automation and AI to streamline processes and reduce manual effort.
Integration: New technologies enable seamless integration with other systems and data sources.

3. Reduce costs:

Maintenance overhead: Legacy EGL applications can be expensive to maintain due to limited skill sets and support.
Infrastructure costs: Modernization can reduce hardware and software costs by leveraging cloud-based solutions.

4. Enhance security:

Vulnerability risks: Older applications are often susceptible to security threats.
Compliance: Modernization can help meet industry regulations and data protection standards.

5. Unlock business opportunities:

Data-driven insights: Modernized applications can leverage big data and analytics for better decision-making.
Innovation: New technologies and platforms enable innovative products and services development.

6. Talent acquisition and retention:

Skill gap: Finding developers with EGL expertise can be challenging.
Attracting talent: Modernizing aligns the technology stack with current industry standards, making the company more attractive to skilled professionals.

7. Future-proofing the business:

Technological advancements: Staying up-to-date with technology is essential for long-term success.
Agility: Modern applications are more adaptable to changing business needs.

In essence, modernizing EGL applications is not just about updating the technology; it’s about transforming the business to be more efficient, competitive, and customer-centric.

We offer various solutions, including upgrades and transformations, to migrate your legacy EGL applications to a more modern architecture. Visit our EGL modernization page to learn more.

Brownfield software development guide

Brownfield refers to physical land requiring clean-up, upgrades, or development before leveraging the property for new purposes. Brownfield software development describes maintaining, upgrading, migrating, interacting with, or leveraging data from legacy applications.

Most of the world’s developers work on and within brownfield applications and environments. While greenfield software development gets the industry buzz, it’s the brownfield technologies with mass adoption and most usage that run companies.

Challenges in brownfield software development

Brownfield software development is not easy. The developers must keep brownfield applications up-to-date, transform critical legacy business logic to modern technologies, and architect interoperability between brownfield and greenfield applications and environments. Some key challenges with brownfield software to note are:

Not having a thorough understanding of the legacy applications and their dependencies with other legacy platforms
Staffing technical expertise to continue the development and maintenance of legacy applications
Developing a strategic modernization roadmap and rapidly executing it while reducing technical risks and business disruptions
Determining which parts of legacy applications are business-critical and must be preserved, maintained, migrated, replaced, or retired
Managing upgrades, migrations, integrations, and modernization of legacy applications in a consistent, uniform, and repeatable manner while continuing active maintenance (no halts in development).

The inability to adequately address these issues and challenges will have a costly impact on the current and future business.

Adopt continuous modernization to help solve brownfield application development challenges

Instead of the obsolete top-down / waterfall approaches in greenfield applications, development teams have adapted leading DevOps principles such as continuous integration (CI), continuous testing, continuous monitoring, continuous security, and continuous delivery (CD) to take a more agile and iterative approach. Incorporating the continuous modernization (CM) principle to brownfield applications should be a natural extension of DevOps to enhance and fully complete the cycle of software development, maintenance, and evolution.

The principle of continuous modernization is to avoid the need for large, time-consuming, costly, and risky undertaking of major modernization initiatives in the brownfield software space. Executing a continuous modernization strategy requires different processes and automation tools to manage software migrations, modernizations, and upgrades while coexisting with ongoing greenfield and brownfield development projects.

One such tool is MLP, a SaaS platform that brings a uniform upgrade process, a collaborative work environment, and transparent and traceable workflows to continuous modernization. It snaps into your existing CI/CD environments and procedures to give you the ability to apply new software updates systematically and incrementally to your in-house applications, APIs, or any other software components.

Benefits of continuous modernization for brownfield software

Leveraging automated modernization workflow management tools and platforms like MLP for brownfield software upgrades, maintenance, integrations, and modernizations will benefit the business in many ways. Some of the benefits offered by continuous modernization for brownfield applications are outlined below:

Accelerate adoption of native, cloud-first, and mobile application architecture
Fast-track digital transformation projects to accelerate delivery of business value
Reduce security risks associated with legacy applications
Keep currency with a rapidly changing technology landscape
Improve performance of brownfield applications
Continuously eliminate creeping technical debt
Prevent massive modernization initiatives in the future

In short, continuous modernization makes it easier to support brownfield application development by providing a systematic, uniform, and accelerated approach to executing modernization roadmaps without disrupting the day-to-day business operations.

Learn more about continuous modernization.

Modernization: from dreaded word to strategic enabler

By Charles Araujo. This article was originally published by Intellyx.

I remember the dreaded words ringing through the house, “Charlie, it’s time to clean your room.”

I pretended I didn’t hear, but inevitably and begrudgingly I stopped what I was doing and began the chore.

Once I was done, however, my mom explained that with my room clean we could now begin the process of transforming it from a child’s bedroom into the teenage haven I had been begging for incessantly.

Getting everything tidied up, it turned out, was the prerequisite to the transformation I so desperately wanted.

Much like “clean your room,” the term modernization has long been a dreaded word in the world of IT.

Uttering it causes involuntary shudders up the spines of IT leaders as they imagine all of the hard work, pain, and suffering to come — with almost no upside at the end of this particularly arduous road.

More importantly, the thinking has gone, while modernization is necessary, investing in it will take precious resources away from more progressive and business-critical initiatives.

So modernization efforts have been left for another day. But it is long past time for this pattern to change.

New advances in both technology and methodologies are transforming modernization from a chore into a strategic enabler — one that may now be the essential component of successful transformations in the digital era.

The problem with modernization

The trepidation surrounding modernization efforts has been well-warranted.

So-called legacy environments — the targets of modernization — are often Byzantine structures that organizations have built layer-by-layer, over the years. Each successive layer has made these systems more complex, more rigid, and almost impossible to change.

As a result, these legacy architectures have become frozen-in-time even as organizations rush to adopt modern technologies in other parts of the technology stack.

With support costs continuing to rise, organizations are recognizing that many of these legacy systems are increasingly becoming liabilities. Still, organizations have seen the pathway to modernization as daunting as they have associated it with the need to completely rewrite and rearchitect these complex and intertwined environments.

These perceived complexities, which have inhibited modernization efforts, however, are now having an even more significant effect. Organizations realize that they must connect their new, modern environments to the legacy systems responsible for core business processes to deliver the sort of end-to-end experiences that customers, partners, and employees demand.

The lack of modernization has now become a roadblock to the business transformations that are vital to an organization’s future.

This situation has left enterprises between the proverbial rock and a hard place. But perhaps modernization doesn’t need to be so difficult after all.

Three shifts that transform modernization

As the need to modernize has become a strategic imperative, both enterprises and tech companies have been exploring ways to overcome its historical challenges.

Those organizations that are finding success with their modernization efforts have discovered that the answer lies in three shifts at the intersection of new technologies and new modernization approaches.

Shift #1: from linear to iteration

First, progressive leaders have realized that they had to stop looking at modernization as a linear, one-dimensional process and, instead, see it as an iterative, modernization lifecycle.

This approach recognizes that modernization demands are themselves continually changing and that modernization is a continual effort that organizations must treat as such.

Shift #2: the move to model-driven

Second, they realized that it was a misconception that was holding them back. They believed that they could only modernize by re-platforming (attempting to transition an existing codebase to a new platform) or via Herculean “rip and replace” efforts in which they completely rewrote an application using modern code and architectures.

They have found greater success, however, with a model-driven approach in which they replicate application functionality, but do so using a combination of a refactored codebase and architectural transformation on modern platforms.

Shift #3: analysis & automation required

Finally, they realized that achieving this type of transformation demands codebase and workflow analysis to deconstruct and manage the modernization effort properly — and that this type of detailed analysis required automation. To achieve this third shift, organizations needed new technologies that would complete this analysis, do automated code conversion, and perform the architectural transformation in a holistic manner.

By making these three shifts, these leading organizations have been able to transform their entire approach to modernization.

The Intellyx take: from roadblock to strategic capability

For most of IT’s existence, modernization has been a nuisance. It has been something that enterprise leaders knew they should do, but which was also a burdensome chore that they would put off if at all possible.

More recently, however, the lack of modernization has become a strategic roadblock.

These rigid and challenging-to-change legacy environments are now inhibiting organizations’ ability to create the type of end-to-end experiences their customers demand.

Bringing a fresh perspective and approach to the modernization challenge, however, is enabling leading organizations to transform their modernization efforts from a roadblock to a strategic enabler.

Those organizations that can modernize their legacy environments most rapidly and effectively, in fact, are realizing a strategic advantage over their competitors that are unable to do so.

This competitive potential is why these leading organizations are turning to companies, such as Synchrony Systems, to give them the tools they need to modernize while sidestepping many of the historical challenges that kept them tied to the past.

The need to modernize legacy systems will only grow in importance as organizations drive forward with their transformational efforts. Those that get modernization right and turn it into a strategic enabler will be the ones that win in the Digital Era.

About the author

Charles Araujo is an industry analyst, internationally recognized authority on the Digital Enterprise, and author of The Quantum Age of IT: Why Everything You Know About IT is About to Change. He is a Principal Analyst with Intellyx, the first and only industry analyst firm focused on agile digital transformation. He has authored three books and published over 100 articles. He has been a regular contributor to both InformationWeek and CIO Insight Magazine and has been quoted or published in magazines, blogs, and websites including Time, CIO, CIO & Leader, IT Business Edge, TechRepublic, Computerworld, USA Today, and Forbes.

Synchrony Systems takes mobile features live in 45 seconds versus three months [VIDEO]

In this short video, Synchrony Systems CEO Slavik Zorin discusses how IBM Bluemix dramatically accelerated mobile application delivery for BART. Reflecting on the experience, he explains how an integrated cloud development and DevOps environment reduced what would traditionally take months into a matter of days—highlighting the practical impact of streamlined provisioning, deployment, and publishing processes.

Bluemix offers the customers today one place where you can do rapid development with services that can be bound, can be dynamically provision on the fly. And not only that you can do development there, but you can actually do the whole DevOps process of publishing and of getting the products to run there, getting your software to run there immediately.

The mobile pilot application that Synchrony Systems is building for BART is for their operations to get real time status information about cars. That pilot is using Bluemix, it’s running in Bluemix, and it’s using the entire DevOps Bluemix development environment to put an application in production. Hopefully, that extends today their existing legacy application that they are using, the web-based application that they are using in-house.

BART was discussing mobile with Synchrony Systems for a while, but it has always been a challenge to hit the ground running. So with Bluemix, what we are able to do is tell them, “Look guys, let us show you what it takes to put a system in production without all the headaches of trying to figure out what it means to get your interfaces with mobile platforms, get the appropriate software in place to provision the right hardware.”

One of the glaring results that we’ve seen here is once we started using Bluemix and building this application is that instead of the typical six months’ effort that an organization would take to build an application like that, it took us 15 days from concept to a running system.

And that is potential going forward, cost savings for BART of possibly in the area of 80 to 90 percent. They no longer have to be afraid of six-months to one-year to two-year project engagements. They can see that systems like that can go from inception to production in about 15 to 20 to 30 days. Now that’s a huge benefit.

Synchrony’s Slavik Zorin speaks at the BlueMix and delivers DevOps keynote address at the IBM Innovate 2014 [VIDEO]

At IBM Innovate 2014, Synchrony Systems took the stage alongside IBM and Bay Area Rapid Transit to demonstrate what real modernization looks like in practice. In this keynote session, our CEO, Slavik Zorin, walks through how we helped BART extend a mission-critical mainframe system into a modern mobile application using IBM Bluemix and DevOps automation. The result was not a risky rewrite, but a rapid, secure extension of an existing system of record into a new system of engagement. The video below captures that moment and the approach that continues to define how we help organizations modernize complex enterprise applications with clarity, speed, and control.

S1 00:04 – Steve, IBM

So it’s been an exciting ride with Bluemix, and I’m very hyped over this application. So and I get tired of charts. I get tired of charts. So how about we see some live code? Does that work for you? It’s always a little high risk, but showing code at a developer conference is about like having a heart attack at a medical group. So it’s not a bad place to be. So if you start to see things come down, please rush the stage and help us out. So we’ve got BART here with us today, and what we’re going to show is pretty cool. So we’ve been talking about this whole notion of system of record and system of engagement. So we’re going to show how we’re actually taking a database, and we’re going to be drilling right into their mainframe in San Francisco and showing how we use Bluemix to extend that with mobile capabilities. So we’re really going to truly show that system of record turning into a system of engagement. So I’d love to introduce to the stage– we’ve got Ravi Misra, CIO of BARTS, Slavik Zorin from Synchrony Systems and Corey Grimes, as well. Big round of applause. [music] Ravi, thanks for joining us. I appreciate all the help. And why don’t you tell us a little bit about BART?

S2 01:34 – Ravi Misra, BARTS

Oh, thank you, Steve.

S1 01:35 – Steve, IBM

Appreciate it.

S2 01:36 Ravi Misra, BARTS

Good morning, everybody. The San Francisco Bay Rapid Transit district is a heavy-rail public transit system that connects the downtown of Oakland, San Francisco to the surrounding cities. BART operates 5 lines, 104 miles of track, 44 stations in 4 counties. BART started operations in 1972. With average, we did traffic of 400,000 passengers. It is the fifth busiest, heavy-rail rapid transit system in the United States. So that’s 400,000 people looking for service every day, on-time performance. To support the round the clock operations, BART relies on the maintenance and reliability information system called MARIS. MARIS is a maintenance system which is used by BART operations to make and break trains, to look at the status of the trains, and some very mission-critical web-based application that is used by supervisors and engineers to track the status of our cars.

S2 02:51 – Ravi Misra, BARTS

But there’s something missing. It’s not mobile. While our workforce is mobile, the application is not. So we had to do something about this to provide a better response and better service to our customers. We decided it was time for us to explore some options. So we called on Synchrony Systems, the team that we had a lot of confidence in, as they had successfully migrated our legacy application from a plank server environment to a web 2.0. This time, Synchrony brought to our attention the possibility of using a cloud-based solution. This is where we were introduced to the possibility of developing using IBM Bluemix Cloud platform. Slavik gets excited about technology. I get excited about results. The key factors that helped us choose to pilot with Bluemix were speed of development, production deployment, a secure access to our on-premise database because we didn’t want the database to reside in the Cloud. Today, you’ll see a demo of the mobile app and how it was developed. And the results are impressive. Thank you.

S1 04:34 – Steve, IBM

Ravi, thank you so much. Fantastic, wonderful job.

S3 04:37 – Slavik Zorin, Synchrony Systems

Thanks, Ravi. Thank you.

S2 04:38 – Ravi Misra, BARTS

Thanks.

S1 04:39 – Steve, IBM

Slavik?

S3 04:40 – Slavik Zorin, Synchrony Systems

How are you?

S1 04:41 – Steve, IBM

Corey? Demo gods are with us today?

S4 04:44 – Corey Grimes, Synchrony Systems

Absolutely, absolutely.

S1 04:45 – Steve, IBM

Good, good, good. Let’s talk a little bit about what you brought today.

S3 04:47 – Slavik Zorin, Synchrony Systems

All right. Well, we’ve heard from Ravi here about MARIS and the web application itself. And what we have here is the mobile app, and the mobile app that is going to be used, basically, also by supervisors and managers to get real time information as things change in the yard. All right. So the next really, is how we did it. And we did it with Bluemix. And we did use Bluemix and DevOps, actually, to extend the current application, and to extend it with a hybrid cloud, and to provide instant access to the yard tracking on a mobile device. We used the Cloud integration that we can see behind us, the Cloud integration service to connect to the on-premise database, as Ravi stated, in a secure way, and also, the back-end service– the mobile back-end service, in order to get the push notifications to notify. So we’re ready to roll, actually.

S1 05:42 – Steve, IBM

Okay, let’s take a look and see what you have.

S3 05:44 – Slavik Zorin, Synchrony Systems

Please take the app.

S1 05:45 – Steve, IBM

All righty. You have me tethered today.

S3 05:48 – Slavik Zorin, Synchrony Systems

Yep, we do.

S1 05:48 – Steve, IBM

I have to link close with you here.

S4 05:50 – Corey Grimes, Synchrony Systems

That’s right.

S1 05:51 – Steve, IBM

So we see down here the mobile MARIS app. And click on that.

S3 05:55 – Slavik Zorin, Synchrony Systems

Okay, that’s your–

S1 05:56 – Steve, IBM

Excellent. I assume you’ve given me administrator access, so I don’t need a password today, right?

S3 06:00 – Slavik Zorin, Synchrony Systems

Absolutely. Only you [laughter].

S1 06:03 – Steve, IBM

Very secure today, very secure today. So here what I see is Hayward Richmond Daly City and– I’d assume these are railyards?

S3 06:12 – Slavik Zorin, Synchrony Systems

That’s correct. You can tap on one of them, yeah.

S1 06:14 – Steve, IBM

Okay. And then I assume if one’s red, then we may have a problem or–

S3 06:18 – Slavik Zorin, Synchrony Systems

That’s exactly right.

S1 06:18 – Steve, IBM

–a car’s offline or in maintenance.

S3 06:20 – Slavik Zorin, Synchrony Systems

That’s right.

S1 06:20 – Steve, IBM

So I click on one.

S3 06:23 – Slavik Zorin, Synchrony Systems

And we can see– yeah. So this is your track. If you filter it right there–

S1 06:26 – Steve, IBM

You’ve got cars in–

S3 06:27 – Slavik Zorin, Synchrony Systems

You could just watch the tracks that have cars on it, exactly.

S1 06:29 – Steve, IBM

So here we’ve got two red cars on ST15.

S3 06:33 – Slavik Zorin, Synchrony Systems

That’s right. That’s the track 15, and both of them are red. So why don’t we do this? Why don’t we go now to the web system, on-premise? And we’ll take a look and see what information we can–

S1 06:44 – Steve, IBM

What we have going on those cars.

S3 06:45 – Slavik Zorin, Synchrony Systems

Yeah, exactly. So you could see that we have car 2510 and car 1847, actually, that are offline.

S1 06:52 – Steve, IBM

We need that screen up [inaudible].

S3 06:55 – Slavik Zorin, Synchrony Systems

The screen is going to show, but–

S1 06:56 – Steve, IBM

Okay, we’ll get it.

S3 06:58 – Slavik Zorin, Synchrony Systems

But we’re looking at it. We’re looking at it.

S1 06:59 – Steve, IBM

We’ve got a beautiful demo here [laughter].

S3 07:02 – Slavik Zorin, Synchrony Systems

All right. But it would be nice if you could look at it, too.

S1 07:07 – Steve, IBM

So we have a full panel on the server here showing more detail in the cars, etc., as to what’s online or not. Now, you seem to have more information here than what we’ve got on the phone. Can I get that information here?

S3 07:18 – Slavik Zorin, Synchrony Systems

Well, it’s funny you should ask. So we–

S1 07:21 – Steve, IBM

I’m poking, and this is as far as I can go right now.

S3 07:24 – Slavik Zorin, Synchrony Systems

That’s as far as you can go, but we actually prepared for you an implementation, a feature here that we staged on Bluemix.

S1 07:31 – Steve, IBM

Ravi gave you a requirement on the way down today?

S3 07:32 – Slavik Zorin, Synchrony Systems

Gave us a requirement and said that we have to do this before we actually showcase. So we’re going to actually take you through it on Bluemix right now. So what you see here right now is the first part. So this is the stage where we stage the code. You can see the first part, which is the rest call from the node js server application mobile back into the Cloud integration service. And that’s the part that actually gets the data from the on-premise environment, right?

S1 07:57 – Steve, IBM

Yep.

S3 07:58 – Slavik Zorin, Synchrony Systems

Okay, good. You’re going to show the second part. That’s the one that implements the actual method that accesses the Cloud integration. Okay. And that returns the data. And you can see the parameter. It’ll get passed from the client, and that’s how we get, actually, the data. Next, we actually define the get request, we kind of keep walking up. We define the get request and that’s what routes– that’s the URL. It routes to the back-end so that the client gets the car details. And the only thing that’s left now, is everything else that we’ve given the client. So we can switch to the final part, and we can see the four changes we’ve made here. You’ll see that there is a service call to node js mobile back in service. We’ll see that there is a method that actually packages– that long method right there. That’s the one that packages the data that’s going to be displayed on a mobile device. The ven handler itself that actually handles, implements the request, and of course, you’re tapping registration and the event listserv, itself. All right? So these are all the changes that we’ve put together. They’re all staged. And right now, we’re going to be ready to go and actually go through the process of committing it, pushing it, and publishing it. And this is all configured with auto publish, so hopefully, this is going to do it all automatically.

S1 09:09 – Steve, IBM

So with this new feature– I mean, I’ve got to, again, dedicate the server to it. I’ve got to wait, what, three months to put it in production? I should see this about Christmas, right?

S3 09:18 – Slavik Zorin, Synchrony Systems

Yes. 30, 45 seconds.

S1 09:19 – Steve, IBM

30 or 45 seconds [laughter]? Okay, okay. Okay. So we’re going to push that change out. You saw the green bar, so it’s going live. And maybe we can talk about my red cars.

S3 09:30 – Slavik Zorin, Synchrony Systems

All right, maybe we can. So why don’t we do this? Why don’t we switch meanwhile, and actually see what happens if, on the field, we actually fixed it? So let’s go switch the application. And this is the car number 1847, so let’s select car number 1847. And somebody’s actually going to change it to a go state. So now, it’s in the no-go. It’s red, and we’re going to switch it to go. And if you pay attention now, hopefully, as we update the application live, we’re going to be able to see the real time push notification, if everything is working well. Go for it.

S1 10:05 – Steve, IBM

Car status changed. Status is go for 1847 on storage track 15. Fantastic.

S3 10:10 – Slavik Zorin, Synchrony Systems

Fantastic. So if you follow this through, you should be able to see change now live to one–

S1 10:14 – Steve, IBM

So I’m down to one, right? And I’m down to one in here. Fantastic. This is great.

S3 10:19 – Slavik Zorin, Synchrony Systems

That’s right.

S1 10:20 – Steve, IBM

So how about our other change, now? Do you think it’s through?

S3 10:23 – Slavik Zorin, Synchrony Systems

Let’s hope that the publish is completed. We’re going to go back to the dashboard and see if everything is green. Are we all green, Corey?

Cool. So that means we’re going get– it’s exactly right. So we’ll close the application. Reload it back again.

S1 10:33 – Steve, IBM

Okay, so we’ll pull it back up.

S3 10:34 – Slavik Zorin, Synchrony Systems

All right. You can still log in, I hope?

S1 10:36 – Steve, IBM

I’m still the administrator.

S3 10:37 – Slavik Zorin, Synchrony Systems

That’s still administrator. All right.

S1 10:41 – Steve, IBM

So I guess [crosstalk] over there.

S3 10:42 – Slavik Zorin, Synchrony Systems

So you still have one left. Yep. Let’s take a look. If you can now look– see that feature live–

S1 10:49 – Steve, IBM

Fantastic. More car details directly from the database in San Francisco. Fantastic.

S3 10:54 – Slavik Zorin, Synchrony Systems

Outstanding.

S1 10:54 – Steve, IBM

Fantastic. Now, you guys have both been in consulting quite a bit. So we’ve taken an existing database on a mainframe in San Francisco. We’ve done extensions to it, allow for push notifications. We’ve built a mobile app. We’ve added capability to it. How long would it have normally taken you before Bluemix and DevOps?

S3 11:12 – Slavik Zorin, Synchrony Systems

Takes about six months to do something like that, normally.

S1 11:14 – Steve, IBM

How long did it take you to do this product like this?

S3 11:16 – Slavik Zorin, Synchrony Systems

This time, 15 days.

S1 11:17 – Steve, IBM

15 days. 15 days. [applause] Fantastic. Thanks, Slavik.

S3 11:22 – Slavik Zorin, Synchrony Systems

Thank you.

S1 11:22 – Steve, IBM

Corey, thank you so much. Fantastic. Are you excited? I am.