In our previous blog post in this series, Tackling Security Concerns in Application Modernization, we focused on security. In this post, we’re going to go a step further and examine the operations of modern applications as a whole.

Why are operations of modern applications so important?

The advantages of modernizing your systems are well known. Continuing to run legacy systems is a business risk due to them being difficult to change and maintain, and running on aging hardware. There are also many benefits to moving to the cloud, some of which we have highlighted throughout this series. These benefits include:

• Turning data into insights
• Accelerating innovation
• Delivering exceptional customer experiences

However, moving your applications to the cloud isn’t enough – you need to optimize each application to run in the cloud. Not doing so results in excessive operational costs (both in people and infrastructure), extended outages, and performance problems.

Operational inefficiencies can occur with legacy “lift and shift” migrations to the cloud because these applications were not designed to best leverage cloud services. If new, native-cloud applications are not designed properly (for example, including automation and reusable services), then they will be operationally inefficient as well.

With many companies now having private, hybrid and multi-cloud environments, each with their own platform services, environmental complexity is proving to be an operational burden. There is a need to better operationalize these cloud environments with operational design considerations, architecture consistency, and automation.

How are other companies tackling application modernization? Complete this brief survey to find out.

What does operationalizing modern applications mean?

We should consider the robustness and observability of applications when transitioning them to operations. Operationalizing modern applications should include security, monitoring, resiliency, and disaster recovery (DR) requirements, as well as the means to design, implement, and measure the applications run-time characteristics.

Your design goal is to ensure your applications are secure, resilient, and efficient, while also optimizing operational costs. This can also mean things like ensuring you’re not overspending on cloud resources or wasting people’s time. The goal is to be as efficient as possible with both your people and cloud resource consumption while maximizing your application performance and availability within your budget constraints.

First you need to design applications to meet operational requirements. Cloud vendors publish reference architectures for common application types, such as web apps and microservices, to help with this. You should follow these design guidelines and make adjustments for your operational requirements when you’re designing your applications.

Your reference architectures should address operational requirements and result in a more consistent run-time environment across applications. What you don’t want is a bunch of “snowflake” applications, each one different with their own operational requirements. This, of course, leads to increased complexity.

Instead, by automating the build of your infrastructure and the deployment of your applications, you can be more agile, consistent, save people costs, and at the same time implement the operational controls you need to be more efficient.

To fully optimize your applications, you need to consider operations in the following areas:

Resiliency

You need to ensure that the application platform is designed to meet performance and availability requirements. You want to be sure that the applications continue to function despite component failures within a system. The loss of individual components or instances within a system shouldn’t impact the entire application but just a single feature.

To do this, you need to start with good designs, such as those based on a reference architecture. You should build the application with operational requirements in mind and include ongoing monitoring, testing, and optimization. A DevOps culture helps here, as developers and operations have a shared understanding of how software is designed and built and also its run-time behavior.

Security

IT organizations see a significant shift in their security in the cloud, too. Traditionally, IT organizations deployed security controls along with the physical infrastructure in their data center. Conversely, you can, and should, automate native cloud virtual machines, containers, and application level security for modernized applications. Ideally, you want to automate vulnerability scanning and policy enforcement, too. IT organizations have an opportunity to improve security from what it was in legacy data centers, with consistency of architecture an added bonus.

Monitoring and logging

As modern applications are typically in the cloud or deployed on software-defined infrastructure, the way you monitor infrastructure changes dramatically. These newer systems are also typically highly distributed, bringing additional challenges. While you previously monitored a single monolithic application for capacity in legacy systems, modern systems often involve things like software-as-a-service applications and microservices in containers, each of which should have their own monitoring and logging capability.

Highly distributed systems are virtually impossible to monitor without the proper tooling and instrumentation. Tools and approaches like container orchestration and a service mesh can implement monitoring, logging and security in a consistent and automated way. For example, a service mesh can provide the software layer to control and monitor microservices and their interactions.

Disaster recovery

The DR concerns change dramatically in the cloud. The constraints of physical hardware and networks are gone, with inherent redundancy in the cloud ready to be leveraged. While legacy DR involved replicating data centers, the cloud allows you to have multiple instances of applications actively running and ready to take on the workloads of failed components.

In the cloud, you synchronize data in real-time across geographically dispersed application components. This approach puts the processing of transactions and data closer to the user, improving performance as a result. Modern application availability is not a question of DR but of designed resiliency in the cloud.

How does the required skillset change in a modern environment?

As the above requirements and processes show, everything changes when you modernize your applications. While the concepts are similar, things like the application designs, implementation, and tools are all different.

This is the greatest challenge facing IT – addressing the need to migrate legacy applications and the skills gaps that exist to do the work. Many businesses delay migrating because they don’t have the people to make the changes they need. This happens often despite these businesses having applications that are brittle and costly to maintain.

This is where a transformation roadmap is necessary to guide the process. You need a cloud staffing strategy. You need to optimize your applications for operations, else the complexities of the environment will make skills gaps overwhelming. And, you need to ensure your cloud teams are working together to adapt to new-technology challenges and that you are on a path to mature your people skills, alongside your processes and your technology. Then your business will benefit most from modern applications.

Learn more

Click here or fill out your details below to download our guide and learn more about how modernizing your applications can help your business.

In our previous blog post, Create Your Transformation Roadmap for Application Modernization, we looked at what a transformation roadmap typically includes with regard to app modernization. In this blog, we’ll examine the importance of transformation roadmaps, what they include, and the process of creating one.

Why is creating a transformation roadmap so important?

At its core, a roadmap ensures the organization is moving toward its goal while also hitting markers along the way. The roadmap provides direction – both on the work you will do and the budget needed to achieve your goal. You’re essentially looking to marry strategy and architecture and accomplish all of the steps needed along the way with your roadmap.

By design, this roadmap aims to help you fill skills gaps and mature three main areas – your people, processes, and technology. As such, the final goal you work toward is broken up into many smaller goals to help progress in these areas. For example, if your organization wants to increase the speed of the application lifecycle, you may have a goal of adopting a DevOps methodology to do so. This goal would then include teaching people like the development and operations teams new skills, implementing new processes to encourage an agile environment, and adopting new technology to bring automation to your work.

The budget is also important to consider, because you have to play within the rules of your business. A roadmap helps you identify where you need to spend your budget and lays out a timeline to do so. This especially helps in getting executive buy-in for your efforts, where budget is often the first thing to come to mind. You may need to consider laying out a roadmap over multiple years because of your budget, while ensuring your plans align with business priorities is a must.

Those that don’t plan and gain executive support can often see their projects fail. They may miss the mark on some key aims: namely, struggling to adopt the technology and failing to mature skills and processes for the technology. These failures result in significant losses of both time and money.

Gain insight into similar companies’ business goals for application modernization.                                               Take this quick survey to see how you compare.

Key components of a transformation roadmap

As highlighted in the previous blog in this series, a transformation roadmap typically includes:

• Your organization’s goals and barriers
• Journey maps for your customer experience
• Assessment and inventory of your technology
• Gap analysis and recommendations
• IT goals (e.g., cloud first, agile, DevOps)
• Technology options and reference architecture
• Application portfolio rationalization and migration options (e.g., build versus buy)
• Budgets, benefits, and timelines
• Change and communication plans
• Program governance (e.g., organization, roles and responsibilities, dashboard KPIs, accountability)
• Digital products and marketplace offerings
• Program execution in the context of goals (e.g., agility, innovation, DevOps)

The key behind the roadmap is showing why the business is investing in the application modernization efforts. How will your end goal benefit the business, and why did you choose the goals along the way as priorities?

Where you’re categorizing apps as part of your roadmap, it’s important to consider both business and IT attributes. These include:

Business metrics:

• Business domain
• Strategic focus/investment themes
• Operational effectiveness
• Revenue generation
• Usage/user count
• Relative user experience

IT metrics:

• Support costs
• Data and integration quality
• Architecture alignment
• Code quality
• Reliability
• Agility
• Security

Who is involved in creating the transformation roadmap?

A roadmap requires buy in from several stakeholders throughout an organization, which means many people are involved in creating it. First, as previously mentioned, you need to align your goals with business goals, which means you need to take a top-down approach to figure out what you want to achieve. As such, you will need executive buy-in and final reviews when it comes to launching the plan.

When looking at specifics, you’re going to have to work with teams to know what progress needs to be made in their areas. Interviews with application teams are necessary for specific business domains. You also need to review architecture and processes such as testing and change management, as well as input from operations, compliance, and security. The goal of this is to essentially understand how IT aligns with the business and ensuring that it is an innovative team that works toward business goals.

Many organizations don’t have experience with creating a roadmap, and may look to a partner to assist. As an experienced partner, we have the people with the experience and skills to lead and participate as subject matter experts in any application modernization project, along with a methodology with reusable templates and reference architecture.

Learn more about app modernization

Click here or fill out your details below to download our guide and learn more about how modernizing your apps can help your business.

The blog “5 Ways Your Data Warehouse Is Better In the Cloud” outlined the advantages of running your data warehouse in the cloud. In this blog, we look at the high-level considerations for migrating your data warehouse to the cloud.

Building the Business Case for Migrating Your Data Warehouse

Many companies facing expensive on-premises product renewals are aggressively migrating their data to the cloud. In this case, the cost of migrating to the cloud can be offset by the cost avoidance of the upgrade and migration. It is important to recognize product end-of-life cycles and plan a migration to the cloud accordingly. Insufficient lead time for a migration due to end-of-life dates would likely result in a less than optimum lift-and-shift migration.

Building a business case requires a TCO calculation for each data warehouse option considered. Cost should be gathered for data center/compute expenses, networking, data transfer, storage, administrative, software license/subscription fees, hardware and software maintenance, depreciation, and support. Fault-tolerance and disaster recovery is inherent in the cloud and is expensive to achieve with your own data centers. You should include these costs in the TCO model as well.

Intangible benefits typically associated with the cloud like agility and elasticity are more difficult to quantify. However, you should include these as benefits within the business case.

A recent Perficient client TCO study found the cost of the enterprise data warehouse (EDW) in the cloud to be significantly less than on-premises due to the following factors:

• Disaster recovery cost in the cloud was minimal and primarily made up of data storage and data transfer costs.
• Separating storage and compute with pay-as-you-go compute minimized overall costs.
• The ability to right-size and scale the compute environment minimized initial costs of the program.

Technology Selection for Your Data Warehouse

There are many options to run your EDW in the cloud. Businesses require a strong knowledge of cloud architectures, data lakes, elasticity and storage options, cross-region redundancy, and cloud subscription models to make technology choices. The leading public cloud providers have many data-related services and continue to innovate rapidly. There are also many third party options to choose from.

Your data-related technology selections and the roadmap to implement them must also align to the business strategy and priorities, your overall cloud strategy, and the direction you want to take your BI and AI in the cloud. The ability to support or migrate your existing data movements, ETLs, and security model must also be considered.

Using a partner with cloud platform and data migration experience is often something worth considering. This is especially the case for technology selection and migration planning.

Data Warehouse Migration Style

As previously stated, an EDW product end-of-life upgrade spend could force you to a lift-and-shift migration scenario. If this is the case, it should be considered a tactical stop in the overall data warehouse roadmap. A lift-and-shift migration will not produce an agile EDW or optimize the elastic cloud environment.

Another option is to create a new cloud EDW for a specific set of use cases. Businesses should select these use cases carefully so that they leverage the cloud with all the associated benefits. For example, businesses could build a new EDW in the cloud for a specific business unit or to support a specific data science use case. This more incremental approach would build internal cloud skills and prove the value of data in the cloud to the business and thus build momentum to continue the migration. This approach could provide analysts and data scientists new capabilities such as streaming data, AI/ML, and sandboxes for self-service BI.

Getting Started

The EDW is an attractive cloud use case. Businesses often already have their data in the cloud thanks to their software-as-a-service-based applications or already-migrated applications. For those that don’t have data in the cloud yet, their data will likely be there soon. As a first step, migrating the EDW and BI is lower risk than moving your transactional systems. On top of that, there are also many financial and technical benefits to moving the EDW to the cloud.

Perficient has experience with EDW-to-cloud migrations and partnerships with all leading vendors in the space should you need any help. Our cloud EDW, business intelligence, performance management, and predictive and risk analytics solutions incorporate industry expertise, years of experience, and insights from hundreds of successful implementations.

According to RightScale’s eighth annual survey, “Cloud Computing Trends: 2019 State of the Cloud Survey”, “A significant number of public cloud users are now leveraging services beyond just the basic compute, storage, and network services.” The survey says relational database services is the most popular extended cloud service and “data warehouse moved up significantly to the third position.” It’s no surprise that as data volume, velocity, and types have exploded, companies are looking for a more agile and cost effective solutions for their data management and analytics strategies in the cloud.

The following topics outline the advantages of data storage and the enterprise data warehouse (EDW) in the cloud.

Cost Savings

The TCO of a cloud-based EDW is lower than that of on-premises when variables such as redundancy and disaster recovery are included. There are the added benefits of avoiding a large initial capital expense, the ability to try it before you buy it (reducing financial risk), and the ability to process large, one-off analytical workloads with elastic compute and storage and only pay for what is consumed.

Performance and scalability

With elastic compute and storage you never have to worry about a lack of hardware impacting performance. You do however need to pick the right data management tools for the job to ensure requirements are met. There is an expansive set of data services available on the cloud and performance is straight forward to test in the cloud paying for only the resources you use during tests.

Agility and time to value

You can quickly deploy new databases and services without the concern of expensive capital investments or hardware lead times. You can also rapidly try new and innovative tools and approaches in the cloud. For example, you could experiment with streaming data, AI and ML. You could set up sandboxes for user groups and self-service BI. And, in the cloud you have endless capacity for applications like storing sensor data for IoT.

Modern cloud architecture

Elastic compute, on-demand provisioning of infrastructure and global connectivity makes tasks like deploying new databases, federating data, replication and redundancy for disaster recovery easier than on premises. Also, innovation on the cloud is happening more rapidly than in on premises data centers allowing you to experiment with the latest technologies like serverless functions and AI.

Enable new capabilities and data growth

It is easier to experiment in the cloud and handle high volume and high velocity data. You can keep data longer and store more diverse data types and sources. Combining data availability and the modern data services available on the cloud is a great way to add new data capabilities.

Getting started

There were early concerns about cloud security. However, recent surveys show that many believe the cloud to be more secure than legacy systems. The cloud has strong perimeter security, controlled access, and cyber security experts monitoring and auditing security. Moving your data to the cloud is a good time to look again at cloud security policies and architecture.

Data and BI is a great way to get started on the cloud. EDW and BI is lower risk than moving your transactional systems. And there are many financial and technical benefits as outlined above.

Perficient has experience with EDW to cloud migrations. And partnerships with all the leading vendors in the space should you need any help. Our Cloud EDW, business intelligence, performance management, and predictive and risk analytics solutions incorporate industry expertise, years of experience, and insights from hundreds of successful implementations.

This is the next installment in a series of blogs on the subject of cloud transformation and building cloud-native applications.

In Gartner’s report “Top Emerging Trends for Cloud-Native Infrastructure” published May of 2019, they say “…leaders are keen to invest in cloud-native infrastructure technologies to increase software velocity; enable developer agility, application scalability and resilience; and reduce technical debt.” The report also states that while “leaders are keen to exploit cloud-native infrastructure technologies, production deployments are still constrained by a skills gap and lack of technical know-how”. Most companies see clear benefits to moving to cloud-native technology and applications but many lack the skills needed to get there.

The capabilities for building greenfield cloud applications has changed dramatically over the past decade. AWS launched in 2006 with three services and has over 165 services today. Netflix began their move from a monolithic architecture to an AWS cloud-based microservices architecture in 2009. Docker was released to open source in 2013 followed by Kubernetes in 2015. And, AWS Lambda introduced serverless computing to the public cloud in 2014. The pace of innovation in the cloud space is staggering. While many companies have not yet built out capabilities for containers, we are facing a new wave of innovation and application implications for the serverless approach.

Given that most companies want to adopt cloud-native and have a cloud skills gap, it is beneficial to manage a cloud-native transition as tracks within a program. For the cloud-native transition program, maturity targets, training programs, and technology acquisitions can be managed within tracks – for example as follows:

Past blogs in this series have address the need for cloud migration planning, reference architecture and guidelines, and organizational structure and governance.

At a high-level the following steps address the needs for a transition to native-cloud development:

• Establish your container and serverless platform strategy
• Create a cloud skills development strategy
• Select and adopt the right tools for your environment and culture
• Create lightweight architecture guidelines and best practices
• Start small, measure and gauge effectiveness and adjust for emergent patterns
• Embrace and evolve DevOps capabilities including CI/CD automation and application monitoring
• Build automation, security, and compliance into your application and CI/CD lifecycle
• Architect applications as collections of microservices running in containers or serverless
• Selectively migrate monolithic applications to the cloud

Developer’s guidelines for building and deploying their cloud-native applications should be lightweight with a focus on developer experience and Agility.

The following guidelines would be helpful for developers making a transition to cloud-native development:

• 12-factor app guidelines – customized to the cloud environment
• Language and framework standards – e.g. Spring Boot
• Platform specific best practices – e.g. AWS, Azure, GCP, PCF, Kubernetes, Docker, and OpenShift
• Security implementation guidelines, network, scan automation, patch
• DevOps – provision, deploy, CI/CD guidelines
• Runtime standards – service mesh, application performance monitoring, logging
• Migration guidance – when, why and how to migrate legacy monoliths
• Microservices reference architecture and design guidelines

Perficient has teams of highly experienced cloud strategists, architects, DevOps, and change management experts should you need any help with your cloud-native transition. We have invested in developing cloud reference architecture and training experienced individuals on the latest development approaches including native cloud development, PaaS, DevOps, microservices and re-platforming.

This is the next installment in a series of blogs on the subject of cloud transformation. In general, a center of excellence (CoE) is a team of experts whose mission is to provide the organization best practices, guidance, and governance around a specific practice field. Establishing a CoE is often a first step to introduce new technology to an organization. A CoE addresses knowledge and skills gaps and establishes a path to organizational maturity in the topic of interest.

With regard to a cloud CoE (CCoE), IT cloud related surveys invariably cite skills gaps and talent pool shortages as major challenges to cloud adoption.

A CCoE addresses the cloud skills challenge and should be a part of most organizations cloud skills development strategy. The CCoE has a goal of maturing the organizations cloud delivery capabilities.

Gartner defines a CCoE as follows: “A cloud center of excellence (CCoE) is a centralized cloud computing governance function for the organization as a whole. It serves as an internal cloud service broker (CSB). It acts in a consultative role to both central IT, business unit IT and consumers of cloud services within the business. A CCoE can serve the needs of both agility-focused and efficiency-focused IT. It is a key ingredient for cloud-enabled IT transformation and is typically helps drive that transformation.”

Gartner’s definition of a CCoE is broad with an emphasis on governance – i.e. establishing a cloud brokerage, policies and guidelines. But equally important in many organizations, especially initially where quick wins are vital, is rapid developer enablement. In this blog, we will look at steps to establish a CCoE. This means balancing a quick start with immediate benefits to the long-term organizational needs for governance and maturity.

The Cloud Center of Excellence mission and goals should be aligned with the business as a whole. Which translates to the CCoE being structured to facilitate the corporate cloud strategy and application migration plans.

It is important to formally define a cloud strategy, if one does not exist. The rationale, scope and approach to migrate to the cloud can vary greatly. Common approaches to cloud migration include application lift-and-shift (re-platform with little change), replacement with software as a service (SaaS), and refactor/rewrite.

Your cloud migration strategy will greatly impact the focus of the CCoE. For example, if the scope of a cloud migration is part of a larger corporate-wide digital transformation, then the scope of the CCoE will be broad and must include cross-functional leadership from stakeholders across the business and IT. A CCoE for a company that largely replaces applications with SaaS will be different that a company that is mostly rewriting applications – the latter with a focus on application engineering and the former with a focus on application integration.

CCoE leadership is often provided by an executive sponsor and a steering committee of cross-functional leaders.

The executive sponsor adds visibility to the cloud migration program. They also have the organizational authority to initiate and communicate change and build a coalition of support across the enterprise. In addition to the executive sponsor, a cloud steering committee can help make strategic decisions and gain cross-functional consensus. Typical duties for the cloud steering committee include: providing strategic direction, approving standards and roadmaps, promoting the adoption of standards, and enforcing compliance policies.

The first step to create the CCoE is to define and ratify the leadership and organizational structure. Workshops with stakeholders can facilitate discussion to define and create models of the CCoE structure, roles, and responsibilities. The CCoE can then be defined as a set of models including a Venn diagram, organizational chart, and RACI matrix.

For complex organizations, it is best to define high-level models and then drill into the details to refine the organizational roles and responsibilities across functional groups – i.e. start with a Venn diagram and proceed to detailed RACI diagrams once you have high-level consensus on the organizational roles.

The CCoE organizational roles will evolve over time as the organization as a whole matures cloud capabilities. For example, a move from a centralized shared-services model to a federated model. It is important to plan for these organizational transitions and to set maturity goals, measured with KPIs, to ensure cross-functional teams progress towards the desired state of maturity. Defining a cloud maturity model, KPIs, and a roadmap toward maturity are needed, especially for large organizations to ensure timely, incremental progress to maturity.

Once you have the organizational structure and maturity plans, it is necessary to define a cloud governance model.

The governance model should be lightweight and helpful versus burdensome and bureaucratic. Focuses for cloud governance include steps to ensure security compliance, implementation of reference architectures, and optimization of capacity and consumption. Tools to define cloud governance include the definition of guiding architecture principles, reference architecture and reference implementations, and workflows and policies. Workflows define the steps and approvals needed for common cloud-related activities. For example, onboarding a new cloud application or creating a new version of a microservices API.

The CCoE can greatly increase the velocity of cloud migration and adoption by providing developers the tools and guidance they need to migrate applications to the cloud and create green-field cloud applications. For example, the CCoE can define reference architecture for common application types, such as 12-factor web apps and microservices.

Also, a deployable reference implementation complete with a CI/CD pipeline is extremely helpful. The ability for a development team to quickly provision their environment and build a new application greatly enhances developer productivity. Further information on this topic can be found in the blog “Establishing Cloud Reference Architecture and Best Practices”.

The concept of a cloud migration factory can be set up within the CCoE if a goal of an organization is large-scale cloud migration. The cloud migration factory embodies the people, processes, and tools needed to plan, execute, and support ongoing workload migrations. More information on cloud migrations can be found in the blog, “Developing a PaaS Migration Strategy”.

The following is a recap of the high-level steps to consider when implementing a Cloud Center of Excellence:

• Align the CCoE with the corporate cloud strategy
• Define the organizational and funding model
• Identify executive sponsorship and the steering committee personnel
• Define the CCoE roles and responsibilities
• Define the CCoE maturity model and KPIs
• Create the cloud migration roadmap (people, process and platforms)
• Define reference architecture and reference implementations for common application patterns
• Define developer’s guidelines, patterns and standards for building and deploying their applications
• Measure with KPIs and evolve the CCoE over time as cloud capabilities mature

Perficient has teams of highly experienced cloud strategists, architects, DevOps, and change management experts should you need any help setting up your Cloud Center of Excellence. Our Cloud Quick Start has CCoE templates, models, best practices, and reference architecture that speeds cloud adoption. We have invested in training experienced individuals on the latest development approaches, including native-cloud development, PaaS, DevOps, microservices, and re-platforming.

Many organizations face cultural inertia against IT modernization. Companies typically treat IT as a cost center because of a history of expensive programs with cost overruns and missed deadlines. In a recent IDG survey, 64 percent of respondents cited outdated/legacy IT infrastructure among their top barriers to IT transformation. Therefore, implementing IT modernization strategies has become critical.

Digital continues to disrupt industries. As a result, legacy business models have to transform – and with a sense of urgency. IT must lead as an innovator and be the source of new digital business models and products. Leading organizations continue to deliver distinct business value using the most current data in the most consumable way.

Digital initiatives are the top priority for 2019. Only four percent of organizations have no digital initiative at all. This signals an overall shift to digital as a mainstream platform, according to Gartner.

Without a rapid change, many companies will be caught in a death spiral. The longer they wait to change, the more radical the change must be in order to survive.

2 IT Modernization Strategies to Consider Now:

1. Take a Phased Approach

Compelling reasons for modernizing legacy IT applications and processes include:

• facilitating business agility
• participating in the digital economy
• improving customers’ user experience

All considered, to modernize legacy systems, you must simultaneously address platforms, people, and processes to transform IT. This requires planning and organizational change management, including monitoring and making adjustments for ongoing business and market changes. Start with an incremental IT modernization program. Planning for incremental benefits and rapid paybacks reassures business leaders that IT is on the right track. As a result, this builds momentum and secures funds for future investment.

2. Create a Roadmap

From a strategic perspective, address and remediate systems with the greatest potential to positively impact your business in terms of revenue, cost, and customer experience. Creating a migration roadmap aligns your business goals and desired outcomes with systems, plans, and activities that add incremental value throughout the transformation.

When considering your IT architecture, analyze and model the current state of your application portfolio. Categorize systems by complexity, risk, dependencies, and business capabilities. Then, align your strategic and architectural views to create a comprehensive transformation roadmap. Lastly, create model diagrams of future-state application architecture that show transitions over time and reflect the future organization of your application domain and reference architecture.

SUCCESS STORY

Refreshed Apps Recover Loss in Market Share

We helped a financial services client that was losing customers to more innovative competitors. The company’s systems were established on mainframes. Consequently, it had a poor set of client-facing applications.

The business wanted to rapidly implement more engaging customer-facing applications, but it lacked the platforms, people, and process to support more modern applications.

Our approach included:

• a platform selection
• best practices
• IT organizational change
• an innovation lab
• a series of incremental project wins

We helped the client quickly deliver a mobile application that, from the user’s perspective, seamlessly integrated with the mainframe. As a result, the engagement jump-started a successful three-year IT transformation.

Want More Digital Transformation Advice?

My insights into IT modernization strategies for this blog post draw from Perficient’s e-book, “How to Make Digital Transformation Gains in 2019.” In it, my fellow Perficient Chief Strategists and I share real-world examples from conversations with today’s leading brands at various stages of digital transformation. Our 10-chapter e-book features our business insights, actions to take now, and client success stories. Download it here or via the form below.

Stay Tuned

This blog series is part of a special series inspired by our e-book. In the next post, my fellow Chief Strategist Jim Hertzfeld will share advice for how to stay on top of customer expectations.

Subscribe to our Digital Transformation weekly digest here to get the blog posts automatically delivered to your inbox every week. Or, follow our Digital Transformation blog for this series and advice on the topic from all of our thought leaders.

About the Author

Eric Roch has more than 30 years of experience in Information Technology. He’s held various roles with responsibilities around enterprise architecture, strategy, operational excellence, and software engineering. With 15 years of executive leadership in IT consulting, his related business experience includes IT strategic planning and the management of profitable, high-growth consulting organizations. His technical experience includes enterprise architect for distributed systems, SOA and APIs, legacy migration, cloud computing, and DevOps.

In the post “The Business Case Justification for PaaS” we looked at the benefits and a business case for PaaS and the post “Developing a PaaS Migration Strategy” outlined ways to migrate applications to PaaS. In this blog we will look at the steps to create a reference architecture and developer best practices to get the most benefits from your platform.

As cloud infrastructure service providers continue to add platform services to their offerings and pure-play PaaS vendors grow their market share, the available options to build applications has exploded. Companies that do not have any guidelines on the use of cloud computing face the risk of cloud sprawl, where the proliferation of cloud instances, services and service providers grow out of control.

Most companies cannot operate as unicorn startup companies and are constrained by budget, regulations and compliance concerns, and available talent to build their applications. Picking the right services for your application should include considerations for price, scalability, availability, manageability, security and compliance. There are hundreds of services available from a single cloud provider with new services added at a staggering pace. Application developers need architecture guidance on the best services to use for their solutions to control cost, deliver faster and ensure compliance.

The pure-play PaaS model is said to be “opinionated” giving the developer everything they need to build applications within the constraints of the platform. This approach inherently limits the number of options available to developers to build applications, which works well as long as the application domains are limited – e.g. 12-factor apps. But going outside of the application domains supported by the platform, for example IoT, could prove to be problematic and require additional services.

The first step to define PaaS architecture guidelines is to define your application domains (types of applications) and the services used to build each domain. Domain specific application scenarios include 12-factor web app, microservices, big data / batch / analytics, IoT, etc… Then for each domain define a specific reference architecture to build an application within that domain. Also, a deployable reference implementation is extremely helpful. The ability for a development team to quickly provision their environment and build a new application is highly beneficial and will speed the adoption of PaaS.

The reference architecture should define and diagram the CI/CD pipeline to build and deploy the application, the PaaS services and configurations used in the solution, utilities for cross cutting concerns like monitoring, and guidance on capacity and sizing. The reference architecture should also define and document required security and compliance details, which can greatly speed the delivery of applications in a regulated environment.

For applications that fall outside of well-defined domains it is helpful to define a catalog of services recommended to build applications.

A service catalog is a curated list of services that are approved and compliant within the enterprise, for example within the following categories:

• Compute and Networking
• Storage, cache, content management and delivery services
• Database and analytics services
• Security and identity management services
• Application services – AI, mobile, IoT, etc.
• Application tools and management services – control, monitor, test, deploy
• Environment management services – monitor, control, build

The service catalog should be categorized and include attributes for price, scalability, availability, manageability, and security. Company specific attributes such as compliance, projects where used, contacts for SMEs can also be added.

Some cloud service providers offer a service catalog via a marketplace or application tiles and the ability to customize the services available to developers. This is an appealing developer user experience for consuming services and helps with adoption especially if the ability to provision services is automated.

Finally, it is helpful to provide developers guidelines, patterns and standards on building and deploying their applications.

These standards should be lightweight with a focus on developer experience and Agility. For example, the following guidelines would be helpful for the 12-factor web app and microservices domains:

Native Cloud Development Guidelines

• 12 Factor App guidelines – customized to the PaaS environment
• Language and framework standards – e.g. Spring Boot
• PaaS – technology specific best practices e.g. AWS, Azure, GCP, PCF, Kubernetes Docker and OpenShift
• Security implementation guidelines, network, scan automation, patch
• DevOps – provision, deploy, CI/CD guidelines
• Runtime standards – service mesh, application performance monitoring, logging
• Migration guidance – when, why and how to migrate legacy monoliths

Microservices Architecture (MSA)

• MSA reference architecture for containers and application services
• Development standards and guidelines
• Domain Driven Design
• API Standards
• DevOps tools and guidelines
• Integration standards and patterns – APIs and events

Perficient has teams of highly experienced cloud strategists, architects, DevOps and change management experts should you need any help with your cloud architecture and implementation. We have invested in developing cloud reference architecture and training experienced individuals on the latest development approaches including native cloud development, PaaS, DevOps, microservices and re-platforming.

According to Gartner, “It is impossible to provide the platform for any digital strategy and run an effective API program to benefit from the API economy, without full life cycle API management.”

Digital platforms such as mobility and IoT require businesses to establish an API platform strategy that supports new computing models such as hybrid cloud and SaaS. API management solutions are now available in the cloud as a service and offer significant cost savings and deployment flexibility over older on-premises, API Gateway appliances.

When considering an API management platform, look to the key product features to build a business case. API management justification often includes increasing the velocity of the business transformation and the financial justification of legacy renewal cost versus the subscription cost of a cloud-based solution.

Consider also the following typical added capabilities from migrating from an API Gateway to API Management in the cloud:

• Provides a secure API gateway for developers, partners and mobile devices to applications and data
• Manages an internal API program providing a centralized, collaborative environment to catalog and control reusable integration assets and APIs
• Creates an ecosystem of innovation by onboarding APIs and developers into a developer portal

A modern cloud-based API management architecture has the following benefits:

• Faster innovation and time-to-value due to improved developer productivity with self-service access to use and publish APIs
• Lighter weight architecture that can be accessed across many platforms including cloud, mobile and IoT
• Lower cost and risk with the subscription cost typically less than the renewal cost of proprietary software and appliances

Take a look at the graphic below to see a typical API Gateway Migration timeline:

Perficient has been in the integration space for over 15 years and has partnerships with all of leading players.  Contact our team to get details on our Accelerated Migration package.

In the post “The Business Case Justification for PaaS” we looked at the benefits and a business case for PaaS. In this blog we will look at the steps to create a migration strategy to PaaS including re-platforming legacy applications.

Re-platforming applications includes lift-and-shift (containerizing) applications with minor changes, refactoring applications to adhere to twelve factor app guidelines and complete application rewrites to best leverage native cloud and DevOps. Optimizing applications for PaaS often includes changes to improve horizontal scalability, a move from commercial to open-source software, and leveraging application services like database, caching and logging.

Most large companies have built a portfolio of applications over many years that includes custom and commercial-off-the-shelf (COTS) software. It is not possible, or desirable, to migrate the entire portfolio to PaaS. Not all applications will be appropriate for PaaS and the benefits of migrating applications will vary across applications.

Large-scale application migrations require an inventory of applications, a categorization and prioritization of those applications and a prescribed migration plan. Most companies will need formal IT budgets and timelines that may span multiple years.

When looking at the application portfolio holistically, most large companies will find applications that are outdated and have duplicated business capabilities across systems. Many of these applications can be migrated to SaaS, consolidated within packaged applications or deprecated altogether. It is important to reduce the size of the application footprint considered for migration and to determine the level of effort justified to spend on optimizing each application.

From a business perspective, it is best to invest in systems that have the greatest business impact in terms of revenue, cost and customer experience. Application migrations are often tied to a larger business-level, digital-transformation strategy. In the strategic view, a migration road map aligns business goals and the desired customer outcomes with systems plans and activities that provides incremental business value for each application migrated. By starting with high-value applications business value can be delivered early in the migration. This most often translates to migrating customer-facing applications first.

From an IT perspective, it is necessary to analyze and model the as-is state of the application portfolio and categorize systems in terms of complexity, risk, dependencies and business capabilities. In the IT view, application migrations to PaaS may be a part of a larger cloud-first strategy. The business and IT views then must be aligned to create a comprehensive transformation road map. The road map should also address IT capabilities (e.g. DevOps) and platform readiness – people, process and platform. Budgets, timelines and application transition diagrams can be created based on the higher-level road map.

Migration Road map

The first step is to inventory and categorize the candidate applications for migration. During the inventory use a template to capture application details (such as, contacts, business domain, user counts, programming language, etc.). Some applications may be eliminated or postponed from the migration list based on technology fit, lack of use, etc.

The remaining candidate applications should be prioritized based on a set of evaluation criteria such as the following:

Business Metrics
• Business Domain
• Strategic focus / investment themes
• Operational effectiveness
• Revenue generation
• Usage / user count
• Relative User experience

IT Metrics
• Support costs
• Data and integration quality
• Architecture alignment
• Code quality
• Reliability
• Agility
• Security

Next, you can categorize the migration strategy for each application for example as follows:

• Retire
• Migrate to SaaS
• Migrate to PaaS
• Lift-and-shift to IaaS
• Re-architect, refactor / rewrite
• Leave on-premises

Then, applications that have been selected for PaaS migration need to be assessed for an application level migration plan.

At this point automated tools can be used to gather application run-time details, code analysis and supplemented with interviews to collect the following information:

• Application profile – workload characteristics, application architecture
• Non-functional and disaster recovery requirements
• Programming language and framework support
• Application native OS dependencies
• External dependencies and integrations
• Application services requirements – database, logging, session management, etc.
• Build and deploy requirements
• QA lifecycle – test cases, automations, dependencies, etc.
• Level-of-effort estimates and environment sizing

Once you have a solid migration plan here are some tips to get started with your migration:

• Select and adopt the right tools for your environment and culture
• Start with a proof of technology and be prepared to make changes
• Set up the tooling environment, lightweight architecture guidelines and best practices
• Limit the initial scope (start small), measure and gauge effectiveness
• Adjust and incorporate emergent patterns and best practices

Perficient has teams of highly experienced strategists, PaaS developers, DevOps and change management experts should you need any help with your migration. We have invested in training experienced individuals on the latest development approaches including native cloud development, PaaS, DevOps, microservices and re-platforming.

PaaS Service Offerings

Within the cloud delivery models Platform as a Service (PaaS), the model providing the facilities for full life cycle application development, has a smaller overall market share than IaaS or SaaS. However, the PaaS growth rate is accelerating with Gartner predicting a 26% PaaS growth rate to reach $15 billion by the end of 2018.

Private PaaS, containerization and data-intensive applications are fueling the PaaS growth rate. PaaS service offerings have matured and many of the latest platform announcements by the large cloud vendors have shifted from IaaS to PaaS.

This post looks at PaaS benefits, a business case and potential workloads for PaaS. Perficient has partnerships with all of the leading cloud and pure-play PaaS vendors and as such we work on a great deal of PaaS implementations. These implementations vary from operations focused lift-and-shift migrations to greenfield digital product development.

Interviews with client’s and reviews of customer case studies where used to compile the following list of PaaS benefits:

• Significant application lifecycle velocity improvements – release engineering, deployment and life-cycle management
• Application portability across IaaS providers, private and hybrid cloud
• Application scalability and availability – auto-scaling, elastic infrastructure, operational services
• Automated provisioning and builds – CI/CD, DevOps
• Reduction of operating expense – a shift to open source, operational efficiencies, platform consolidation
• Application services marketplace – database, caching, security, logging, API management, etc.
• Consistency of architecture – Spring and Docker ecosystems, microservice patterns, etc.
• Security and compliance – automation, scans, rapid patches, stable-documented environment
• Simplified and centralized administration using containers and container orchestration
• Operational services – security, logging, dynamic routing, load balancing, etc.
• Application monitoring and availability management

Many PaaS case studies point to a business imperative to change the application development approach to achieve greater velocity and operational scalability. The well-known public case studies for Netflix and Google for example chronical their moves to technology such as cloud computing, DevOps, and containers. They, among others, invented new application and platform approaches to achieve the scale mandated by their business model.

But many companies now feel the threat of digital disruption or see the opportunity for digital products to increase revenue. We are seeing companies implement PaaS due to a business imperative to shift to digital products. In fact, Gartner says by 2022 PaaS will be used “in over 33% of new application designs oriented toward digital business solutions.”

Formal cost justification of PaaS solutions is often tied to specific products most often customer-facing digital products or platforms such as e-commerce. Systems-of-engagement benefit the most from improvements in development lifecycle velocity.

Systems-of-record typically change less frequently and are more problematic to move to PaaS. A PaaS purchase can be easily tied to a specific product since the pricing model is usually subscription or usage based. It’s easy to start small with greenfield applications and grow the platform as business value is added and measured.

Another common use case for PaaS is an operational focused lift-and-shift of legacy applications (e.g. a Java application server farm) to PaaS. These efforts focus on containerizing applications to retire server farms, software licenses and the costs associated with them. There are also tangible labor costs and outage reductions, and performance improvements that supports the business case for PaaS.

It is best to consider both software development (full-lifecycle) and operational benefits together for the business case and also, more importantly, for the platform architecture requirements. PaaS efforts lead by operational teams often fail to fully consider product development requirements.

Operations lead PaaS migrations can lean towards a container orchestration solution versus one that also encompasses application services (such as CI/CD, database, cache and API management). A collaborative approach to migrating applications to PaaS leads to a more comprehensive solution and encourages a culture shift to a DevOps operational style.

It is often desirable to change some application level components during brownfield application migration such as moving from commercial to open source software, which may require application changes. These costs must be factored into the cost-benefit analysis.

There are many less obvious benefits we have seen with PaaS. For example, security is improved by automation (such as scans during deploy), platform consistency and the ability to rapidly patch vulnerabilities. Platform consistency can also greatly reduce the time spent on compliancy for regulated companies and government agencies. Containerized software and open source allows software to be more readily shared across business entities and government agencies.

We have seen improvements in engineering staff capabilities and reductions in turnover attributed to PaaS platforms. And, PaaS can improve availability promoting a shift in staff focus from operational administration to proactive application health management.

Perficient has partnerships with all the major PaaS vendors and provides services for PaaS migrations from planning and architecture to implementation should you need any help.

Microservices are gaining popularity for their potential to deliver scalability, resilience, and agility that wasn’t possible with service-oriented architecture. Over 70% of organizations are investigating microservices adoption, but many are encountering challenges to success in achieving these goals with the additional strain on IT to be more agile, adopt new technology, and embrace DevOps.

The Open Group defines Microservices Architecture (MSA) as “a style of architecture that defines and creates systems through the use of small independent and self-contained services that align closely with business activities.” In contrast to monolithic applications, where deployed software and infrastructure are centralized, MSA is highly distributed and requires new approaches to the development lifecycle as well as infrastructure monitoring and management.

Just as Martin Fowler said in his blog post, “In particular with microservices there are serious consequences for operations, who now have to handle an ecosystem of small services rather than a single, well-defined monolith. Consequently if you don’t have certain baseline competencies, you shouldn’t consider using the microservice style.” He goes on to list the need for rapid provisioning, basic monitoring and rapid application deployment as prerequisites for microservices.

But the changes within IT needed for MSA is greater than just operations. A survey of over 2,000 software engineers by Lightbend found the greatest obstacle to microservice adoption was corporate culture – as cited by 46% of respondents. Also, the immaturity of operations tools was listed as a concern for 34% of IT professionals. A culture shift to an Agile development lifecycle and a DevOps approach is needed for MSA to achieve the goals of scalability, resilience, and agility. And the operational tools needed to monitor and manage microservices must be integrated as part of the underlying platform architecture.

Given the complexity of MSA and the need for an IT culture shift to implement microservices, it is helpful to assess where you are on your MSA journey and make plans to mature your MSA related people, processes and platforms. The following sets of criteria can be used to assess your current MSA capabilities and to develop a roadmap, maturity model and KPIs needed for improvement.

MSA Platform Assessment

Many IT organizations lack or have gaps in the culture and processes needed for MSA. Criteria to assess IT organization and governance includes:

• IT alignment to business drivers and imperatives
• Roadmap for legacy systems and data – modernization, cloud-native and monolith migration
• Agile development lifecycle
• Engineering skills and skill gaps
• CI/CD automation and a DevOps culture
• Test first and API first development approaches
• API management and light-weight governance

MSA requires a platform for building and operating cloud-native services that automates and integrates the concepts of DevOps, continuous delivery and containers. Criteria to assess platform architecture capabilities includes:

• Service provisioning and auto-wiring
• Service discovery
• Elastic scaling
• Resource scaling
• Integration with the infrastructure
• Multi-node cluster configuration and management
• High-availability
• Security issues like single sign-on
• Multi-tenancy and isolation
• Monitoring
• Logging
• Routing
• Load balancing
• Instant rollback and versioning
• Service naming and URL mapping
• Polyglot language and persistence support
• Authentication service integration
• Application configuration management
• Orchestration

API management is a critical component for MSA to manage secure assess, monitor component availability and enforce governance and change management. Criteria to assess API management capabilities includes:

• Developer Portal
• Administrative Portal
• Security
• Traffic management
• Transformation
• Proxy
• Analytics
• Versioning
• Lifecycle management
• Metadata Documentation / Content Management
• Social media support / blogs
• Throttling
• Service level management

Perficient’s Microservices Health Check

Perficient has built a practical approach to implementing microservices. We create a roadmap to modernize and mature IT people, process, and platforms needed for effective microservices strategy. To this end, we have developed a Microservices Heath Check to assess IT’s current state and make a series of actionable recommendations within program tracks to modernize IT for micoservices.

The intent of the health check is to create a set of actionable tasks to get microservices processes and projects on track to ensure you achieve the desired technical and business objectives. The Microservice Health Check provides the following benefits:

• Solidifies the microservices business case
• Provides a benchmark of your current microservices approach to industry best-in-class
• Validates architecture concerns such as platform capabilities, security, operations and API management
• Helps to define your microservices roadmap to mature people, process, and platforms along program tracks
• Leverages Perficient’s microservices architecture, agile methodology, and DevOps guidelines
• Delivers a set of actionable tasks to get your microservices program on track

Perficient also has sample microservices deliverables and references available on request.