devopsy.kinsta.cloud

Author: Wilko Visser

  • Governing Microservices in an Enterprise Architecture

    Governing Microservices in an Enterprise Architecture

    Software development strategies continue to evolve to meet changing business needs. There has been a lot of discussion of digital transformation recently, and custom software development is driving much of that transformation. Agile software development and DevOps have become the norm as companies strive to develop better, faster, more flexible applications. Microservices offer the next step in the evolution of enterprise application development.

    DevOps separates developers (Dev) and operations (Ops) into teams collaborating on new enterprise solutions. Similarly, microservices expand on the idea of specialization, creating specialized app building blocks to build new applications. Microservices enable an even shorter development time and greater agility. They also present a new set of challenges for enterprise architects who must oversee these microservices and govern the development process.

    A Series of Building Blocks

    If you are unfamiliar with the term, microservices are a series of building blocks assembled to make new applications. Just as agile software development is a philosophy as well as an approach to development, microservices are an architectural and organizational approach to enterprise software development.

    The value of microservices is in the building block approach. With old-school monolithic services, you must design and maintain a single application and its various components to act as a unit. Change or remove one element, and the entire application needs to be rewritten and tested, which is costly and time-consuming.

    With microservices, the individual services function as self-contained functional units that can be mixed and matched as needed to create different custom applications. Using microservices is faster, more versatile, and more reliable, simplifying the delivery of large, complex applications.

    Microservices also are built around business capabilities so that business application components can be created in tandem with DevOps agile enterprise development. And with different teams working to create smaller components, there is less chance of having a single point of failure.

    No-code/low-code development solutions are placing the power of microservices in the hands of business users. Domain experts in product development, finance, logistics, and other departments can use a drag-and-drop interface to develop microservices that can then be incorporated into other applications. In short, microservices gives subject matter experts the tools to create custom apps that can be added to the enterprise architecture.

    The Pros and Cons of Microservices

    Microservices offer businesses and enterprise architects several benefits. Deployment of new applications is faster, and you have more flexibility to adapt to changing enterprise and business needs. They also scale quickly and make it simple to add new features to existing applications. And microservice elements are reusable.

    Of course, there are challenges as well, including governance. As the architecture evolves, there are more components to be managed. In addition to different departments building microservices, the DevOps team is still responsible for overseeing application development and solving everyday problems. Having a mature engineering culture helps automate app development and track microservices, providing the necessary guidance to ensure app development supports larger business objectives.

    Microservices also create architectural overhead. Applications must be documented to ensure ongoing business value. Trying to document everything, however, creates delays, so the documentation is never current with the stage of development. The challenge is providing enough documentation to be useful without delaying ongoing software changes.

    This requires a new enterprise application mindset. DevOps needs to closely watch autonomous teams to control development and ensure they support larger corporate goals. The use of no-code/low-code tools also could result in shadow IT not being sanctioned by the network architects or DevOps.

    Governing Development

    One of the market forces driving microservices adoption is the need for “outside-in” application development. All microservices should be developed at the request of a customer, whether that customer is inside or outside the organization. Customer requirements continually change, and microservices can accommodate those changes faster and more efficiently.

    Microservice development works best in a domain-driven architecture, which models the applications based on the organization’s real-world challenges. A domain-driven architecture assesses the enterprise infrastructure in light of business requirements and how to fulfill them. Most organizations already have a domain-driven design strategy in place that maps the architecture to business capabilities.

    Bounded Context is a strategy that is part of domain-driven design. Autonomous teams responsible for microservices are formed around areas of responsibility such as inventory management, product discovery, order management, and online transactions, i.e., bounded context. The domain expertise resides within the team, so the enterprise architect’s responsibility is to guide development to align with strategic goals, balancing immediate needs and future business objectives.

    When governing microservices as part of the enterprise, applying the C4 model for software architecture—context, containers, components and code—makes sense. The context defines the relationship between the customer or end user and the application. The container represents the microservice itself and how it is packaged to serve as an application building block.

    The secret to governing microservices in any enterprise architecture is to map business capabilities to the digital infrastructure, then promote the vision behind the enterprise architecture as well as the guidelines to achieve that vision. Focus on organization-wide objectives for both business transformation and IT strategy. Educate the stakeholders on when to involve the enterprise architect. Also, try to anticipate topics beyond the perspective of the DevOps team and focus on the big picture—what is the long-term business strategy and how do microservices contribute to that strategy?

  • Crafting an Agile Enterprise Architecture

    Crafting an Agile Enterprise Architecture

    Digital transformation, business agility and enterprise architecture are frequently heard terms in this era of digital technologies and rapid change. The appropriation of digitalized applications, solutions and processes has enabled organizations to increase efficiencies. In turn, this allows them to respond to shifting customer needs and trends in a more flexible and agile manner. 

    Digital transformation, the rise in mobility and a remote workforce have created a shift in the business model paradigm. The adoption of a more agile approach has been gathering steam, and businesses that are building agility into their processes are seeing the payoffs. The results are greater productivity, faster time-to-market (TTM) and increased consumer satisfaction.  

    The Culture of Agile 

    Digital transformation succeeds in a business environment that embraces a more collaborative and flexible philosophy. Moving from simply doing agile business processes to being agile across the board requires a shift in the corporate mindset. When a business develops a truly agile architecture, everyone in the enterprise is involved in delivering solutions; from business operations and tech to marketing, finance, compliance and security. The agile culture moves from a company-oriented one to a people or customer-oriented culture, embracing the tenets of collaboration, co-creation, ownership, flexibility and communication.

    Short-Term Cycles and Fluid Planning

    Agility is redefining enterprise architecture from the traditional schematic of centralized governance, lengthy development cycles, scheduled quarterly reviews and reliance on a waterfall delivery method. Instead of long-term operating and strategy plans, agile enterprise architecture involves short-term cycles and fluid planning that is customer and market-centric. The language changes from top-down project mandates and management to continuous product development, experimentation, testing and monitoring within collaborative product teams. 

    Essentials for Crafting Your Agile Enterprise Architecture 

    The blueprint for a truly agile architecture requires fundamental shifts in the business dynamic. There are three essentials that stand out as requirements for attaining agility across the entire enterprise. 

    • Collaboration – The bedrock of successful enterprise-wide agility is collaboration. Innovation will flourish when it is decentralized, and isolated silos give way to cross-functional, agile and self-organizing teams. An isolated IT team leads to delayed projects, overrun budgets, productivity that is hard to measure and disconnects between business and operations. Every department must be involved in supporting and achieving key business goals. 

    Teams containing a mix of business line and IT professionals accelerate development and delivery, greatly reducing time to market. Based upon a shared customer-centric goal and vision, there is shared ownership of outcomes and a deeper level of engagement throughout the enterprise. Daily communication and collaborative feedback nurtures creativity, problem-solving, and drive continuous integration and continuous development. Collaborative input from colleagues, inside and outside the organization, is essential for enterprise, technology, and solution architects. 

    • Current state mapping – Adopting agile practices and principles throughout an enterprise entails potentially massive change. Without a clear roadmap for navigating the process, a business can flounder. Instead of achieving a leaner simplicity, there is increased complexity and a muddied vision. Before a business can successfully embrace an agile architecture, the current state of operations must be fully understood. Essentially, a blueprint of functionalities, capabilities, applications, and the tech stack must be crafted. Everything, from the data catalog to business process workflows must be mapped. Business leaders can ask the following questions to analyze the current state and assess impact points:
    • Which projects should we prioritize and what capabilities will they require?
    • Which processes rely upon what software applications?
    • If we remove one or two apps, how will that impact processes?

    Once the blueprint of the current state is mapped out, a business can work in a structured way to create the future state of its architecture with ease and at its own pace. 

    • Balance agile transformation with daily operations – Continuing to work with some of the current architecture for a time can allow the top level of the organization to ease into adopting the agile mindset and culture. In the iterative process of developing agile architecture, the architects, executives, and tech leaders will need to strike a balance between transforming initiatives and effectively maintaining daily operations. They will have to discern how much direction is needed versus support and how much they will set the pace.

    If the focus is first on value delivered to customers, then the architecture will be prioritized according to the most strategic projects, capabilities and applications. An agile architecture will adopt a ‘just enough’ approach to project design and delivery. 

    Agile Architecture Optimizes Collaboration

    Enterprise agility facilitates more direct communication and involvement of enterprise architects within the cross-functional teams. Through daily discussions and various touchpoints, architects can provide guidance, advice, and feedback on IT decisions and assist teams in jointly owning the solutions. 

    Working together, enterprise and solution architects can develop a complete view of the IT landscape and how it will need to be modified to fit into future needs; minimizing waste and optimizing resources. Solution architects can view the architectural map across all apps, solutions, and systems and collaborate on improvements. They can also help enterprise architects scale standardization across the entire business. That cornerstone of collaboration at the core of agile transformation enables architects and non-tech leaders alike to gain more clarity and alignment.

    The Value of Agile 

    Business value is greatly improved when enterprise architecture combines agile practices. According to a report from McKinsey & Co., businesses transitioning to more agile models can improve financial performance by 20-30%, with 30-50% improving operational performance, TTM, and customer satisfaction scores. Embedding an agile model within processes, people, and technology will cultivate ongoing support for CI/CD, groundbreaking innovation, synergistic collaboration — and ultimately maximize customer outcomes.