Tag Archives: application architecture

The Journey of Legacy to Modern Infrastructure Architectures

Posted on by

Current-day literature regarding digital disruption and technology modernization commonly discusses legacy-monolithic infrastructure/applications and modern-day architectures such as microservices. However, less literature exists on the journey from legacy to modern infrastructure architectures. In this blog post, I aim to provide a high-level roadmap to help organizations navigate their technology (infrastructure/application) architecture modernization journey.

To start, let’s introduce the concept of greenfield and brownfield. In the second edition of The DevOps Handbook, authors Gene Kim, Jez Humble, Patrick Debois, and John Willis discuss these concepts in their original terms. Initially used in urban planning and building projects, greenfield is when buildings are built upon undeveloped land. Brownfield development is when we build on land previously used for industrial purposes, potentially contaminated with hazardous waste or pollution [1, p. 66]. In this blog post, greenfield represents new, unbuilt infrastructure and systems, and brownfield represents existing infrastructure and systems with complex interdependencies.

An organization’s strategy has a lot to do with how IT disciplines move forward with building infrastructure and systems. Many organizations have a “cloud first” strategy today or are striving to become “cloud first” throughout their modernization journey. This means greenfield initiatives should be built in the cloud before traditional on-premises (on-prem) infrastructure is used. Using cloud-native technologies to build new infrastructure architectures that support application and data architectures is a surefire way to modernize an organization’s technology stack. In fact, many start-up companies use a “cloud-only” strategy that ensures they don’t introduce legacy systems and technology to their ecosystems from the beginning.

While it’s fair to say that greenfield builds are easier to modernize than brownfield builds is true, it’s not necessarily “easy.” Arun Chandrasekaran (2022) from Gartner, Inc. depicts an illustration showing that the IT workforce has more skill and experience with traditional infrastructure architectures than modern serverless and container infrastructure architectures [2]. From experience, I can attest to Chandrasekaran’s illustration. Unless an organization brings in a small army of highly skilled and experienced cloud practitioners, either via direct hires or consultants, they are bound to experience their share of bumps, bruises, lessons learned, and re-work as they continue to learn and mature in the cloud.

The story changes significantly when it comes to brownfield or already existing systems. This is frequently where digital modernization becomes a journey, and strategy is a major factor in how organizations move their technology architecture forward. Assuming an organization is just beginning its modernization journey, it potentially has a long road in front of it. Even if an organization’s digital modernization journey has already started, the road forward is usually full of turns and hills.

To help with cloud migrations, Amazon Web Services (AWS) describes four phases of cloud migration. The phases include (1) Prepare, (2) Plan, (3) Migrate, and (4) Operations [3]. These phases are an essential component of digital modernization and can be used to help your organization with its migration. Check out AWS’s knowledge article “Phases of migration” for more details on their four phases.

Looking deeper into the migration process, Stephen Orban, author of “Ahead in the Cloud,” Chief Technology Officer at the New York CTO Club, and Vice President at Amazon Web Services [3], outlines six different migration strategies for moving applications to the cloud. AWS commonly refers to these migration strategies as “the 6-R’s.” The 6 R’s include (1) rehosting, (2) replatforming, (3) repurchasing, (4) refactoring/rearchitecting, (5) retire, and (6) retain [4]. All six strategies apply to brownfield builds.

Figure 1: The 6 R’s of cloud migration strategy.

  1. Rehosting, or “lift-and-shift,” is moving your existing infrastructure/systems “as is” to the cloud.
  2. Replatforming, referred to Orban as “lift-tinker-and-shift,” involves using some cloud services to optimize a system, but it doesn’t change the core of the system.
  3. Repurchasing or moving to a different product. This typically involves eliminating brownfield builds and replacing them with Software as a Service (SaaS) solutions.
  4. Refactoring/Rearchitecting is described by Orban as re-imagining how an application is architected and developed, typically using cloud-native technologies.
  5. Retire or simply get rid of. Orban says that between 10% and 20% of an organization’s IT portfolio is no longer useful and can be retired.
  6. Retain usually means “revisit” or do nothing, at least for now. This strategy may be best suited for systems recently brought online on-prem or for organizations early in their cloud migration journey.

Orban says that enterprises usually begin to contemplate how to migrate an application [to new platforms and infrastructure] during the second phase of the migration process – Portfolio Discovery and Planning. A firm understanding of the systems existing in an organization’s IT portfolio is key to creating a migration strategy. Differentiating the low-hanging fruit that can be easily harvested from complex monolithic architectures with multiple interdependencies will help organizations choose the right combination of strategies to suit their migration needs.

“This [portfolio discovery and planning] is when they determine what’s in their environment, what are the interdependencies, what’s going to be easy to migrate and what’s going to be hard to migrate, and how they’ll migrate each application.” – Stephen Orban

As you can see, greenfield initiatives are easier to build in the cloud as they are not subjected to the monolithic and interconnected infrastructure that exists within an organization’s IT ecosystem today. Brownfield initiatives require significantly more strategy, planning, and often time to migrate into the cloud. Organizations will encounter use cases for greenfield and brownfield builds throughout their journey. Having the strategy and skills is vital to a successful digital modernization journey.

References

[1] G. Kim, J. Humble, P. Debois and J. Willis, The DevOps handbook, 2nd ed., Portland: IT Revolution, 2021.

[2] A. Chandrasekaran, Compute evolution: VMs, Containers, Serverless – Which to use when?, Gartner, Inc., 2022.

[3] Amazon Web Services, “Phases of migration,” 2022. [Online]. Available: https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-database-migration/phases.html. [Accessed 9 October 2022].

[4] S. Orban, “Linkedin – Stephen Orban,” [Online]. Available: https://www.linkedin.com/in/stephen-orban-7086471/. [Accessed 9 October 2022].

[5] S. Orban, “6 strategies for migrating applications to the cloud,” Amazon Web Services, 1 November 2016. [Online]. Available: https://aws.amazon.com/blogs/enterprise-strategy/6-strategies-for-migrating-applications-to-the-cloud/. [Accessed 9 October 2022].

[6] Y. Perry, “AWS migration strategy: The 6 Rs in depth,” NetApp Cloud Central, 25 July 2019. [Online]. Available: https://cloud.netapp.com/blog/aws-migration-strategy-the-6-rs-in-depth. [Accessed 9 October 2022].

An Introduction to Service-Oriented Architecture

Posted on by

Today’s application development landscape is paired with many buzzword methodologies and practices: Agile, DevOps, and Microservices, to name a few. Today, I aim to help you gain a foundational understanding of the Service-Oriented Architecture (SOA) methodology, its benefits, and whether it’s a good fit for your organization or not.

Figure 1: SOA Model [2].

According to CIO staff members at CIO.com, SOA is an overarching [software] development strategy based on the concept of building software assets using the service-oriented programming (SOP) methodology [1]. SOP is based on the premise of creating blocks of code (services) that are reusable and can be integrated with many platforms throughout an organization.

As an IT leader within a mid-sized financial institution, I can relate to the example provided by CIO.com. Imagine a financial institution and its services, such as various loans, investments, insurance sales, etc. Each one of these services has its own information system used to drive its business processes. Each information system would likely need the ability to perform a credit check on a potential customer. In many cases, each system has its own mechanism for performing a credit check. CIO.com’s example of SOA is creating a singular, reusable service called “get credit rating” that can be integrated with all the information systems that need to perform a credit check, eliminating the need to “reinvent the wheel”.

Organizations using SOA will realize many tactical and strategic benefits. According to Gartner Inc., creating reusable software components, like the “get credit rating” service mentioned above, can lead to productivity increases and at least a 30% reduction in new development implementation costs [1]. In addition to reusable software and productivity increases, CIO.com says that increased agility is another tactical advantage of SOA. ProFlowers.com is a prime example of increased agility. The organization only has one line of business (selling flowers), so reusable code doesn’t offer an enormous benefit; however, ProFlowers.com found other benefits of implementing the SOA methodology. By breaking apart their monolithic system, they were able to design and build a system comprised of individual software components. This enabled ProFlowers.com to scale its system during peak transaction volume times such as Valentine’s Day and allows them to upgrade individual processes without tearing apart the entire system.

In addition to its tactical benefits, the SOA methodology also has strategic benefits. SOA better aligns the various businesses within an organization by illustrating the big picture of all business processes and flows within the organization. In addition, SOA helps unify the lines of business and IT regarding the importance of Enterprise Architecture (EA). To be candid, an EA deep dive isn’t for everyone, especially since the return on investment (ROI) is often opaque to the business. SOA provides tangible value to the company through its tactical benefits: reusable services, improved productivity, and improved agility.

SOA introduces several benefits to an organization, but is SOA the right methodology for your organization? The answer is “it depends.” CIO.com says SOA may be a good fit if your organization is large and complex, meaning it has “more than two primary systems that require some level of integration” [1]. Companies that have enjoyed the most success with their SOA implementation journeys are big companies with large IT budgets whose business is technology-based, such as telecom and financial services [1].

Adopting the SOA methodology often requires a heavy upfront investment of time and money. It will require the support of senior executives to pave the way for IT to dive into the core business processes of the organization [1]. Organizations need to adopt SOA across the entire organization and establish centralized architecture design, software development, and governance practices to ensure uniformity. Organizations will not realize maximum benefit if SOA is adopted in silos. Services built by siloed teams may have little potential to be reused across the organization.

In summary, the SOA methodology is primarily based on creating small blocks of code to form reusable services across an organization. The methodology offers several benefits but is often associated with high upfront implementation costs. Small or decentralized companies may find it challenging to implement the SOA methodology.

References

[1] CIO Staff, “SOA definitions and solutions,” 19 March 2007. [Online]. Available: https://www.cio.com/article/272203/service-oriented-architecture-soa-definition-and-solutions.html. [Accessed 11 September 2022].

[2] J. Rehman, “Advantages and disadvantages of service oriented architecture,” IT Release, [Online]. Available: https://www.itrelease.com/2018/10/advantages-and-disadvantages-of-service-oriented-architecture-soa/. [Accessed 11 September 2022].

Exploring the EA Application Layer

Posted on by

Figure 1: Domains/Layers of Enterprise Architecture [1].

According to Adam Getz, Program Manager at Excelity, the primary goal of Enterprise Architecture (EA) is to align business and information technology (IT) objectives across the organization. EA enables the process of planning and designing business and IT capabilities across the organization [1]. Getz explains that EA is broken down into four domains or layers: (1) Business, (2) Data, (3) Application, and (4) Technology. The domains (layers) of EA are illustrated in Figure 1.

Every layer of the EA stack is essential and brings important organizational components to light. This blog post will explore the Application Layer and its shift toward modern application architecture. The most basic way to summarize the application layer is the thought of the end-to-end structure of applications. The application layer serves many purposes, from providing an application inventory to support portfolio management to deep diving into architectures such as microservices and data streams [2]. Mike Rose of Technology Transfer says, “The application domain is critical in providing interoperability in support of user experience, in providing flexible services, and managing cost and complexity.” [2].

Application architecture has come a long way in a relatively short time. As a result, modern-day application architecture is shifting in many ways. The first noticeable shift is from monolithic application architectures to modern architectures such as microservices. The second significant shift is the platforms organizations use to host their application architecture, shifting from traditional on-premises applications and supporting infrastructure to Software as a Service (SaaS), Infrastructure as a Service (IaaS), and Platform as a Service (PaaS) offerings.

Traditional application architectures tend to be tightly coupled, monolithic, and complex architectures with large code bases, typically hosted within the organization’s datacenter(s) (on-premises [on-prem]), although not exclusively on-prem. Pictured in Figure 2 (below) is one of the most common architectures you may encounter, a three-tiered stack consisting of web/presentation, application, and database tiers. In these architectures, you will find network infrastructure (firewalls, load balancers, etc.) and server infrastructure (custom-coded or off-the-shelf applications and database back-ends). According to Talend, these systems are designed to handle multiple related tasks. The tightly coupled nature of these systems makes them difficult to manage and update, where an update to a single component of the system could cause an outage of their entire system.

Figure 2: Three-tier application stack [3].

Modern application architecture introduces new technologies and methodologies, such as the Mesh App and Service Architecture (MASA). Gartner Inc. describes the MESA model as providing an evolutionary approach that enables development teams to iteratively and continuously modernize an organization’s applications in direct response to business priorities [4]. The MASA model combines three elementary architectural concepts that support digital business requirements; they are: (1) multi-experience, (2) mediated APIs, and (3) multigrained services. Figure 3 provides an overview of how the three concepts integrate.

Figure 3: MASA Model [4].

The second shift is in the infrastructure that supports the application architecture. Today, many organizations are strategically reducing their data center footprint by using “as a service” solutions such as IaaS, PaaS, and SasS. Utilizing “as a service” offers numerous benefits to an organization, including cost reductions, eliminating the need to purchase and manage hardware, eliminating the need to update software, and increasing system availability. “As a service” platforms are trending in many industries today.

In summary, application architecture is not a new concept to organizations; however, modern application architecture design and delivery are rapidly transforming how organizations design and operate systems and do business today. As a result, the application architecture layer of EA is critical to all Lines of Business within an organization. It plays a significant role in fusing technology infrastructure to conduct business.

References

[1] A. Getz, “Enterprise Architecture – Domains and Pillars,” 16 September 2021. [Online]. Available: https://www.linkedin.com/pulse/enterprise-architecture-domains-pillars-getz-pmp-csm-aws-cmmi/. [Accessed 10 September 2022].

[2] M. Rosen, “Understanding enterprise architecture domains,” January 2021. [Online]. Available: https://technologytransfer.it/understanding-enterprise-architecture-domains/. [Accessed 10 September 2022].

[3] “Three tier architecture: the beginning,” 11 February 2018. [Online]. Available: https://medium.com/coffeetechandme/three-tier-architecture-the-beginning-2d2f6063fa1e. [Accessed 10 September 2022].

[4] “Monolithic vs. Microservices: a guide to application architecture,” [Online]. Available: https://www.talend.com/resources/monolithic-architecture/. [Accessed 10 September 2022].