Tag: cloud enterprise architecture

Categories
erwin Expert Blog

Software Deployment Strategy: How to Get It Right the First Time

Big or Small, Enterprise Architecture Is a Key Part of a Successful Software Deployment Strategy

A good software deployment strategy could be the difference between multiple and costly false starts and a smooth implementation. Considering the rate at which emerging technologies are introduced, it’s becoming more important than ever for organizations to have a software deployment strategy in place.

But what does it involve?

Not all software deployments and investments are equal. Large-scale, big-money investments like ERP require a lot of resources and planning. Small-scale investments, like website technology, on the other hand, can be purchased, expensed and deployed with few people knowing. And of course, there are thousands of software decisions made that fall somewhere in between.

Software purchase decisions and deployments represent an opportunity to leverage the experience and knowledge of your enterprise architecture (EA) team so you can make smarter, better investments. The key here is the EA team’s complete view of your IT landscape, which can help eliminate redundant purchases, identify issues of integration and more.

 

Software Deployment Strategy: How to Get It Right the First Time

Small Projects Can Create Big Headaches

Here’s an example of how a small-scale software investment can wreak havoc on an organization.

There is an intense focus today on customer experience (CX). Ensuring that your website visitors have access to the information they want, and they can find it quickly and easily, is just part of your overall CX. This makes your customer-facing technologies – the ones that power your website or mobile app – critical investments, even though they may not carry the price tag of an ERP system.

Even the smallest investments need to be vetted to make sure they work with existing infrastructure and processes. One small piece of website tech that ends up degrading your online CX can cost your organization millions in a very short amount of time. There’s simply too many choices just a click away today if something isn’t working properly. Differentiating technologies are also more likely to be customized than an application like ERP, which can often use a number of out-of-the-box processes.

These are areas where a software deployment strategy involving your EA team can help guide the software purchase and deployment process. But even in a world where software deployments increasingly mean logging into a cloud-based SaaS application, a software deployment strategy is still beneficial.

Don’t Be Resigned to Failure

Many SaaS vendors like to talk about how easy it is to get up and running with their products, especially when the infrastructure elements are in the cloud. But the reality is that the network that connects to the SaaS application, the security, the integrations with existing (often on-premise) applications, the SLAs and licensing, can all benefit from a review by the EA team.

Failed software deployments are, in fact, a significant problem for many organizations. Such failures can often be attributed to a lack of planning and foresight.

Considering the costs associated with some software – including its purchase, implementation and consultancy fees/training required to get started – a good software deployment strategy could save millions … literally.

A Gartner study found that nearly half (46 percent) of respondents said their most expensive, time-intensive software deployments were not delivering. When Gartner broke the software purchases in question into deal sizes of over and under $1 million, the firm got similar results.

When your EA team has the visibility to see across your IT landscape and understand the business processes built on your technology, it can help provide a better idea of the real costs behind your software deployments and you can better estimate your time to value. When it comes to software investments, you don’t be resigned to failure.

erwin EA gives organizations a full-featured, versatile platform for enterprise architecture in its broadest sense to ensure the success of projects – regardless of their size or scope.

Start your free trial of erwin EA now.

Enterprise Architecture Business Process Trial

Categories
Enterprise Architecture erwin Expert Blog

Agile Enterprise Architecture for DevOps Explained …

How do organizations innovate? Taking an idea from concept to delivery requires strategic planning and the ability to execute. In the case of software development, understanding agile enterprise architecture and its relevance to DevOps is also key.

DevOps, the fusion of software development and IT operations, stems from the agile development movement. In more practical terms, it integrates developers and operations teams to improve collaboration and productivity by automating infrastructure, workflows and continuously measuring application performance.

The goal is to balance the competing needs of getting new products into production while maintaining 99.9-percent application uptime for customers in an agile manner. 

To understand this increase in complexity, we need to look at how new features and functions are applied to software delivery. The world of mobile apps, middleware and cloud deployment has reduced release cycles to days and weeks not months — with an emphasis on delivering incremental change.

Previously, a software release would occur every few months with a series of modules that were hopefully still relevant to the business goals.

The shorter, continuous-delivery lifecycle helps organizations:

  • Achieve shorter releases by incremental delivery and delivering faster innovation
  • Be more responsive to business needs by improved collaboration, better quality and more frequent releases
  • Manage the number of applications impacted by a business release by allowing local variants for a global business and continuous delivery within releases

The DevOps approach achieves this by providing an environment that:

  • Minimizes software delivery batch sizes to increase flexibility and enable continuous feedback as every team delivers features to production as they are completed
  • Replaces projects with release trains that minimize batch-waiting time to reduce lead times and waste
  • Shifts from central planning to decentralized execution with a pull philosophy, thus minimizing batch transaction cost to improve efficiency
  • Makes DevOps economically feasible through test virtualization, build automation and automated release management as we prioritize and sequence batches to maximize business value and select the right batches, sequence them in the right order, guide the implementation, track execution and make planning adjustments to maximize business value

An Approach with an Enterprise Architecture View

So far, we have only looked at the delivery aspects. So how does this approach integrate with an enterprise architecture view?

To understand this, we need to look more closely at the strategic planning lifecycle. The figure below shows how the strategic planning lifecycle supports an ‘ideas-to-delivery’ framework.

Agile Enterprise Architecture: The Strategic Planning Lifecycle

Figure 1: The strategic planning lifecycle

You can see the high-level relationship between the strategy and goals of an organization and the projects that deliver the change to meet these goals. Enterprise architecture provides the model to govern the delivery of projects in line with these goals.

However, we must ensure that any model built include ‘just-enough’ enterprise architecture to produce the right level of analysis for driving change. The agile enterprise architecture model, then, is then one that enables enough analysis to plan which projects should be undertaken and ensures full architectural governance for delivery. The last part of this is achieved by connecting to the tools used in the agile space.

Agile Enterprise Architecture: Detailed View of the Strategic Planning Lifecycle

Figure 2: Detailed view of the strategic planning lifecycle

The Agile Enterprise Architecture Lifecycle

An agile enterprise architecture has its own lifecycle with six stages.

Vision and strategy: Initially, the organization begins by revisiting its corporate vision and strategy. What things will differentiate the organization from its competitors in five years? What value propositions will it offer customers to create that differentiation? The organization can create a series of campaigns or challenges to solicit new ideas and requirements for its vision and strategy.

Value proposition: The ideas and requirements are rationalized into a value proposition that can be examined in more detail.

Resources: The company can look at what resources it needs to have on both the business side and the IT side to deliver the capabilities needed to realize the value propositions. For example, a superior customer experience might demand better internet interactions and new applications, processes, and infrastructure on which to run. Once the needs are understood, they are compared to what the organization already has. The transition planning determines how the gaps will be addressed.

Execution: With the strategy and transition plan in place, enterprise architecture execution begins. The transition plan provides input to project prioritization and planning since those projects aligned with the transition plan are typically prioritized over those that do not align. This determines which projects are funded and entered into or continue to the DevOps stage.

Guidelines: As the solutions are developed, enterprise architecture assets such as models, building blocks, rules, patterns, constraints and guidelines are used and followed. Where the standard assets aren’t suitable for a project, exceptions are requested from the governance board. These exceptions are tracked carefully. Where assets are frequently the subject of exception requests, they must be examined to see if they really are suitable for the organization.

Updates: Periodic updates to the organization’s vision and strategy require a reassessment of the to-be state of the enterprise architecture. This typically results in another look at how the organization will differentiate itself in five years, what value propositions it will offer, the capabilities and resources needed, and so on. If we’re not doing things the way we said we wanted them done, then we must ask if our target architectures are still correct. This helps keep the enterprise architecture current and useful.

Enterprise Architecture Tools for DevOps

DevOps can use a number of enterprise architecture solutions. For example, erwin’s enterprise architecture products use open standards to link to other products within the overall lifecycle. This approach integrates agile enterprise architecture with agile development, connecting project delivery with effective governance of the project lifecycle. Even if the software delivery process is agile, goals and associated business needs are linked and can be met.

To achieve this goal, a number of internal processes must be interoperable. This is a significant challenge, but one that can be met by building an internal center of excellence and finding a solution by starting small and building a working environment.

The erwin EA product line takes a rigorous approach to enterprise architecture to ensure that current and future states are published for a wider audience to consume. The erwin EA repository can be used as an enterprise continuum (in TOGAF terms).

Available as a cloud-based platform or on-premise, erwin EA solutions provide a quick and cost-effective path for launching a collaborative enterprise architecture program. With built-in support for such industry frameworks as ArchiMate® and TOGAF®,  erwin enables you to model the enterprise, capture the IT blueprint, generate roadmaps and provide meaningful insights to both technical and business stakeholders.

According to Gartner, enterprise architecture is becoming a “form of internal management consulting,” helping define and shape business and operating models, identify risks and opportunities, and then create technology roadmaps. Understanding how vision and strategy impacts enterprise architecture is important – with an overall goal of traceability from our ideas and initiatives all the way through delivery.

enterprise architecture devops

Categories
erwin Expert Blog

Enterprise Architect: A Role That Keeps Evolving

Enterprise architect is a common job title within IT organizations at large companies, but the term lacks any standard definition. Ask someone on the business side what their organization’s enterprise architects do, and you’ll likely get a response like, “They work with IT,” which is true, but also pretty vague.

What the enterprise architects at your organization do depends in large part on how the IT department is organized. At some organizations, enterprise architects work closely with the software applications in a role that some might refer to as a solution architect.

In other organizations, the role of enterprise architect might carry more traditional IT responsibilities around systems management. Other enterprise architects, especially at large organizations, might specialize in exploring how emerging technologies can be tested and later integrated into the business.

Technology research and advisory firm Gartner predicts that enterprise architects will increasingly move into an internal consultancy function within large organizations. While this use of the role is not currently widespread, it’s easy to see how it could make sense for some businesses.

If, for example, a business sets a goal to increase its website sales by 20 percent in one year’s time, meeting that goal will require that different IT and business functions work together.

The business side might tackle changes to the marketing plan and collect data about website visitors and shoppers, but ultimately they will need to collaborate with someone on the technology side to discuss how IT can help reach that goal. And that’s where an enterprise architect in the role of an internal consultant comes into play.

Each business is going to organize its enterprise architects in a way that best serves the organization and helps achieve its goals.

That’s one of the reasons the enterprise architect role has no standard definition. Most teams consist of members with broad IT experience, but each member will often have some role-specific knowledge. One team member might specialize in security, for example, and another in applications.

Like the tech industry in general, the only constant in enterprise architecture is change. Roles and titles will continue to evolve, and as the business and IT sides of the organization continue to come together in the face of digital transformation, how these teams are organized, where they report, and the types of projects they focus on are sure to change over time.

Enterprise integration architect is one role in enterprise architecture that’s on the rise. These architects specialize in integrating the various cloud and on-premise systems that are now common in the hybrid/multi-cloud infrastructures powering the modern enterprise.

Enterprise Architect: A Role That Keeps Evolving

For the Enterprise Architect, Business Experience Becomes a Valuable Commodity

Regardless of the specific title, enterprise architects need the ability to work with both their business and IT colleagues to help improve business outcomes. As enterprise architecture roles move closer to the business, those with business knowledge are becoming valuable assets. This is especially true for industry-specific business knowledge.

As industry and government compliance regulations, for example, become part of the business fabric in industries like financial services, healthcare and pharmaceuticals, many enterprise architects are developing specializations in these industries that demonstrate their understanding of the business and IT sides of these regulations.

This is important because compliance permeates every area of many of these organizations, from the enterprise architecture to the business processes, and today it’s all enabled by software. Compliance is another area where Gartner’s internal consultancy model for enterprise architects could benefit a number of organizations. The stakes are simply too high to do anything but guarantee all of your processes are compliant.

Enterprise architect is just one role in the modern organization that increasingly stands with one foot on the business side and the other in IT. As your organization navigates its digital transformation, it’s important to use tools that can do the same.

erwin, Inc.’s industry-leading tools for enterprise architecture and business process modeling use a common repository and role-based views, so business users, IT users and those who straddle the line have the visibility they need. When everyone uses the same tools and the same data, they can speak the same language, collaborate more effectively, and produce better business outcomes. That’s something the whole team can support, regardless of job title.

Business Process Modeling Use Cases