You Don’t Need Another Monolithic Platform

You Don’t Need Another Monolithic Platform

August 03, 2017 0 Comments
You Don’t Need Another Monolithic Platform-2_870x220

It's time to move past the limitations of traditional platforms. Learn the key dimensions to consider when choosing the right software architecture for your business.

Software platforms have come a long way over the years, ping-ponging between converged and distributed systems of processing as technology evolves. It started with mainframes (very converged), then client-server (distributed), then the web server/browser (converged again) and we are now back in a massively distributed era. Information is processed on myriad mobile platforms, voice, AR/VR, and across numerous operating systems and devices. This makes it possible to do a lot of new things for your users, but it also adds tremendous complexity.

It once made sense to try and address your business needs with an all-in-one platform, but these days, do you really need another rigid platform, or everything that comes along with a SOA? That’s the wrong way to think about solving today’s business and technology problems. Many organizations want to move from commercial JavaEE applications servers like IBM WebSphere to open source alternatives like Red Hat. And while this may make sense from a licensing perspective, organizations need to think beyond these technologies to new forms of architecture.

Architectures have developed to the point where you no longer need to consider a closed, restrictive off-the-shelf platform. Platforms like that are liable to become outdated over time and inflexible when it comes to addressing the changing needs of the business. By carefully evaluating on an architecture level instead, you can solve your problems in a more tailored way for your business that enables greater efficiency and long-term success. A MASA is a great example of this kind of architectural design.

At Progress, we believe that instead of picking a monolithic platform, you should be able to pick the right technology for the right business initiatives. There are a number of key dimensions that factor into determining the right architecture for your business. By evaluating along these lines, you’ll be able to ensure that you are choosing solutions that take advantage of today’s technologies and can deliver the success you need for the long term.

Key Dimensions of Software Architecture Design

Abstraction

Abstraction makes it easier to isolate capabilities and reduce complex dependencies between application code and development teams.

Benefits of Architecture Abstraction

  • Facilitates teamwork—Allows different teams to focus on their area of specialization and reduces complexity so the teams can build using an agile approach.
  • Encourages participation—An API approach lets you more easily integrate capabilities from other systems, as well as expose your own capabilities to partners and customers.
  • Future-proof— Promotes the re-use of business logic and data from multiple interface types, including new types like chatbots, etc.

Microservices

By designing your architecture with microservices, applications are easier to develop, manage and deploy, making teams more efficient.

Benefits of Serverless Microservices

  • Flexibility—Properly constructed services, including macro-services that leverage underlying microservices, provide flexibility when it comes to making modifications or pushing new capabilities into production.
  • Focus where it belongs—Using a serverless approach allows your developers to focus on the app, not the infrastructure, and spend more of their time building application services. This approach also takes containerization and DevOps to the next level with increased automation.

Fit for Purpose

Teams across your organization have different needs, and an inflexible platform that cannot adapt can’t possibly serve them all well. An architecture that is fit for purpose makes it possible to work together—efficiently.

Benefits of a Fit for Purpose Architecture

  • Support different constituents—Today’s applications require a broad range of expertise supported by different job roles. A single interface approach for all involved simply won’t work. The user experience needs to be tailored for different roles like frontend developers, backend developers, data scientists, business analysts, content providers, etc.
  • Separate but integrated—While each application participant requires an environment that meets their needs, the end result of their work must be easily integrated. That’s where microservices, APIs and abstraction comes into play.

Internet-scale

Scale is more than the idea of scaling up and down based on transaction/user/data volume. Gartner defines Web-scale IT as “a system-oriented architectural pattern that enables the rapid and scalable development and delivery of Web-based IT services leveraging agile, lean and continuous principles.” You need to be able to scale the right organizational and operational processes to move quickly.

Benefits of Internet-scale

  • More versatile scaling—Scale not only compute capacity for individual workloads, but to support different types of application and user experience workloads, like IoT.
  • Expanded automation—Move beyond just automating technology to “automating everything,” including manual operations that DevOps, data scientists or other key roles are responsible for.

Choosing the Technology You Need

These dimensions are deeply embedded into the technology solutions we build at Progress. Our solutions are best-of-breed at every step, and designed to give our customers and partners critical flexibility when designing their architecture. Our industry-leading frontend UI solutions integrate seamlessly with other backends, and similarly our top-ranked serverless backend services works with other frontends. Or customers can simply adopt our whole stack to build their application, including native cross-platform mobile development, data connectivity, cognitive intelligence and more.

It’s time to move past the search for a restrictive platform and consider an architecture-based “conceptual” platform, based on a cognitive-first mindset. You don’t need another “traditional” platform, you need the right technology.

Mark-Troester-2015-web

Mark Troester

Mark Troester is the Vice President of Strategy at Progress. He guides the strategic go-to-market efforts for the Progress cognitive-first strategy. Mark has extensive experience in bringing application development and big data products to market. Previously, he led product marketing efforts at Sonatype, SAS and Progress DataDirect. Before these positions, Mark worked as a developer and developer manager for start-ups and enterprises alike.

Read next What’s Different Now: 5 Reasons Why AI is Suddenly Accessible
Comments
Comments are disabled in preview mode.