Tag: enterprise architecture

  • 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?

  • How Waterfall Methodologies Stifle Enterprise Agility

    How Waterfall Methodologies Stifle Enterprise Agility

    In this age of sweeping digital transformation and accelerated change, organizations are recognizing that depending solely upon the drawn-out process of waterfall methodology is no longer sustainable if they are to remain competitive and relevant.

    Enterprise infrastructure must incrementally embrace evolution from monolithic architectures in response to the escalating pace of technological innovation, ever-changing consumer needs and demands and the failure of a long-running single project focus.

    EA Must Continuously Adapt 

    Traditional enterprise architecture (EA) frameworks struggle to manage the impact of disruptive technologies and systems that are agile and flexible. An architecture design approach that embraces continual evaluation and iteration is better equipped to navigate change and capitalize on emerging trends and innovations. Adaptability, in this context, may be defined as the fluid ability to modify, restructure and recreate the architecture in relation to changes within and external to the enterprise. It involves the early identification and rapid response to new product concepts, important trends, events and consumer demands; developing a “from the outside in” perspective.

    This adaptability, or ‘evolvability,’ quotient enables the flexibility and agility to deliver services and products reliably in this new development norm. Enterprise leaders are quickly acknowledging the need to inject a more open and agile format into their enterprise’s processes, at least in some measure, to succeed in today’s unpredictable environment.

    The Waterfall Model Constrains Enterprise Agility

    Traditional organizational architecture can impose limitations on an enterprise’s ability to successfully reach its digital transformation goals. The up-front model, with a focus on one long-range project, can slow productivity and choke creativity. While planning is needed as agility scales, the detailed technology life cycles with large timeline projections are no longer effective or profitable in meeting the business mandates that drive enterprises forward. Enterprise leaders are increasingly abandoning the five-year architectural plan for one that is designed to evolve with the ever-changing software development environment.

    Enterprise architects must now develop and promote adaptive methods that support agility in order to appropriate the value of new technologies like AI, machine learning, big data, IoT and intuitive tools that enable advanced analytics and enterprise-wide collaboration. A less intentional architecture, decomposed into smaller units, can be managed by autonomous cross-functional teams that are accountable to peers and managers with shared strategic objectives, bringing all fields into a coherent whole.

    A continuous architecture design with no end state, guided by iterative changes, will fluidly address the changing needs of the enterprise. A shift from a project-oriented to a product-oriented management mindset leads to faster learning cycles, shorter time-to-market, higher quality and increased revenues.

    The Attributes of a Flexible and Adaptive EA

    An open architecture designed to evolve in an ongoing manner and enable agility will include many beneficial characteristics and principles. Flexible and adaptive EA:

    • Provides product-centricity that connects software development to business goals;
    • Explores multiple solutions simultaneously with shorter analysis, testing, experimentation cycles and progression to eliminate weak solutions;
    • Empowers autonomous, cross-functional teams with clear accountability roles and alignment to a shared mission statement and effective information sharing;
    • Enables flexible and efficient resource allocation driven by changing demands or activity levels;
    • Strengthens an evolving roadmap that shows vision and targets, open to the whole enterprise, to allow input and questions for collaboration, cohesion and transparency;
    • Facilitates incremental changes to software architecture in a continuous manner;
    • Provides a continuous integration and delivery model with automatic testing for ‘good enough’ MVPs to keep the business moving forward.

    An adaptive EA allows for timely decision-making as agility scales, ensuring that the right products are delivered at the right time in alignment with business initiatives. When design accountability is distributed across the enterprise, consensus on complex decisions involving diverse stakeholders is more easily attained.

    The business rewards of transitioning to an adaptive architecture should be an easy sell by examining and tracking the monetary, time and customer success gains. The evolution toward adaptive enterprise architecture can reap numerable benefits. In addition to fostering an enterprise culture of continuous improvement, it accelerates and improves development cycles, journeys and outcomes for stakeholders and customers.

    Adaptive EA addresses the inherent uncertainties and complexities associated with dynamic business changes. It can deliver the rapid incremental changes, capabilities and benefits that a waterfall model inhibits. The agile and open methodology, empowered to continually evaluate and modify, provides visibility into project requirements and feasibility to reduce risks typically experienced with a traditional design and waterfall methodology.

    Making the Transition to an Agile EA

    Transforming enterprise architecture to a more adaptive and agile model will require planning and investment. A necessary first step is to assess what the enterprise goals and objectives are in making the transition. To what degree is the organization ready and what needs to be in place in order to move forward?

    Investing in an enterprise-wide training program of agile technologies, principles and methodologies will develop a cohesive and cooperative mindset that overcomes resistance to change and optimizes transition success.

    Of utmost importance is the development of a culture of communication, from the C-suite down across all stakeholders. A shared vision must be communicated and encouraged within a collaborative framework to cultivate enterprise-wide buy-in and acceptance of changes from waterfall methodologies to current roles and practices. In the migration to agile, there can be many obstacles, but by adopting an incremental approach with frequent reassessments an enterprise can ease the transition.

  • What DevSecOps for SAP Looks Like

    What DevSecOps for SAP Looks Like

    In the past few years, organizations have seen a constant increase in cyberattacks targeting business-critical applications and the data within because that data is particularly lucrative to sell or trade. Organizations running SAP software, especially, are struggling, as SAP systems are complex and hard to patch—even worse, information security and cybersecurity teams often don’t understand SAP systems and how to secure them. Traditional security approaches aren’t enough to secure SAP systems, but DevSecOps for SAP could introduce a new approach with better results.

    What is DevSecOps?

    While traditional security often becomes a roadblock to accelerated software delivery. DevSecOps introduces a new security-first mindset that emphasizes security at every step of the software development life cycle and makes everyone in the organization responsible for security.

    DevSecOps includes all departments of an organization and embeds security thinking into the entire process, from the executive board down to individual teams. To make this successful, business operators need tools and processes that support:

    • Continuous monitoring
    • Scanning for security defects
    • Attack detection
    • Change management and governance
    • Regular assessments

    Why is DevSecOps for SAP Changing the Game?

    In the past, security was often neglected while implementing new projects or new feature releases under the assumption that security defects would be resolved later in an existing system by the information security team. This approach, however, introduced additional complexity, costs and business disruption.

    If security considerations are introduced in an earlier phase of a project, security defects can be identified and remediated much more cheaply and quickly. This alone makes it far more efficient and easier to resolve a potentially exploitable vulnerability. With good tools in place, this becomes very efficient and allows organizations to identify and resolve vulnerabilities that have been introduced in earlier iterations of their change processes.

    The biggest benefit, however, is that any new process or feature has been implemented with security by design, leading to a resilient environment that can more easily fend off cyberattacks.

    DevSecOps for SAP

    Here’s an example: Say a new business project is started with the intent to change SAP applications or processes to introduce new functionality. Like with any project, time, budget and available resources are key elements. For DevSecOps to work, important security considerations must be made in early phases of the project. In reality, every single project is a security project. This means that business requirements and targets must not be prioritized over security concerns. Processes and tools are needed to enable development and security teams to work together to answer important questions: Will the project introduce a security impact to contained data and established processes? Similarly, is there a need for additional software and security architecture, or is a specific skill set required that needs to be onboarded to the project?

    In an agile environment, once all epics and user stories have been written, the design phase can start. With a security mindset embedded into the project, this will automatically lead to a solution that is secure by design.

    During the implementation phase, developers need tools to scan for potentially vulnerable source code. 

    Identifying vulnerabilities that allow SQL injection, cross-site scripting or missing authorization checks early on in the development process makes it easier to fix them.

    The challenge here is that SAP does not provide the tools developers need to validate source code for security flaws. The SAP transport management system is vulnerable to software supply chain attacks unless appropriate security patches have been installed. For this reason, organizations need a code vulnerability analyzer that can be integrated within the SAP standard development IDE.

    In addition, quality gates enabled in the SAP transport management system can be very helpful for developers to avoid source code that lacks proper security validation.

    Functional issues discovered in the user acceptance test (UAT) phase must also trigger a restart of the validation cycle. Only when all security and functional requirements are met can production deployment be initiated. In this phase of the life cycle, DevSecOps for SAP focuses on monitoring to enable attack detection, regular (or better continuous) vulnerability assessments and accurate security patching.

    Which Tools are Needed to Introduce DevSecOps for SAP?

    While many organizations already make use of change management and IT service management solutions, they do not yet have all the tools needed to embark on a DevSecOps journey with SAP.

    Keep in mind there are platforms available on the market with an open API that allows integration within already established SAP solutions and provides the missing link between change management and security incident management. These solutions provide a one-stop-shop to securing SAP and reduce TCO compared to individual siloed tools for code scanning and vulnerability management.

  • Organized Architecture

    Organized Architecture

    I’ve mentioned IT pendulums plenty of times before, but today I’m going to use them to explore a different angle on IT: The age of containers and microservices. It’s time to ask yourself if the current architectural design of the overall product offering of IT is the best one you can afford to offer.

    Agile and the whole “developer is king” movement brought us a whole lot of independent app teams running off and doing their own thing. While the core of that movement was short-lived, we got a lot of good and bad out of it. The good included breaking the traditional “We change at glacial rates” process that some IT shops had—because a team absolutely wants the tools that will make their job easier, not the ones pre-approved by committee or whatever process a given org used. And the bad included the very things those of us who’ve seen this type of thing play out before warned about. Suddenly, we had critical apps and infrastructure relying on tools that one dev used in his hobby development. Sometimes that was good, and for sure it happened before Agile came along, but now we had an avalanche of it. Stuff that hadn’t been through security; often code/libraries/apps that no one outside the team (or the individual) knew was running in the organization. Some of that stuff is still happening.

    And then we hit true uptake of microservices. That drove us to break things up in non-traditional ways. A lot of good came of that process, but a lot of complexity did, too. Complexity shared across applications with a huge spike in API calls and operations with a spike in deployed processes and routing. Perhaps the worst thing to come out of the combination of the two is “Who cares why it failed? Just spin up another!” That movement is mostly dead (thank goodness), but it only died because of the number of high-profile “Oops” issues that it caused. It allowed attackers to go unnoticed; it caused paying customers to spread security details across the web; it caused users to suffer crashes that would have been fixed in any sane development environment … and some of those are still out there. Cases where there’s a script to restart an app or service every X hours because it crashes randomly. Not acceptable. Make all the excuses you like, but if you don’t know what’s causing the crash, you’re wrong to leave the app or service running.

    And we introduced a huge amount of complexity. Now we have double the infrastructure—one physical, one virtual (container or cloud). We have applications spread across a lot more systems (be they instances or physical systems) and often across platforms; even across data centers. We live in a very cool time, with some sweet stuff going on. But complexity is a very real problem we need to solve. One app/app portfolio may have limited complexity, but we still allow teams too much leeway in defining the environment the application lives in. We need to offer a happy medium—a world where there are options, but those options are defined, manageable, and secure.

    So we’re likely to see a resurgence in the importance of enterprise architecture teams again, with their focus being on organizing the mess we’ve made. Indeed, I know this is underway in a couple of Fortune 500 companies I stay in touch with. And I know of one organization that isn’t doing this and has all their UI functionality running through a single container … for multiple applications. That is no better architecture than each using a completely different UI toolset. So, I expect they’ll want coordinated solutions also. Just so something like that can’t happen again.

    You all are doing it, day in and day out. As I often say, just don’t let this bit drag you down. Confront it head-on, approach standardization with “Yes, where it is good; no, where it is not” as your credo. Security is the big one, but maintainability is another. Even with tools like Ansible at their disposal, managing 50 different environments is a bit much for ops if it could be done with five. And keep rocking it. Through a pandemic, meeting increased demand, giving users more and more. Thanks once again, from all of those users who don’t know to thank you.

     

  • Microservices Days coming to a city near you

    Microservices Days coming to a city near you

    Microservices is rapidly becoming a design paradigm for developing software. While there are many benefits to microservices designs, it is more complex than traditional application design. For this reason we are formulating a new community around microservices architecture. This community will explore design issues and the intersection with Mobile/IoT, Containers, Cloud, DevOps and APIs.

    Microservices Journal is a newly-launched online community where practitioners can share their experiences and learn from others.

    Microservices Days are a series of regionally delivered one-day seminars led by practitioners.

    Who should attend: CIO/CTO, Application Development Management, Software Engineers, DevSecOps, and IT Operations.

    For our 11/16 program we are lucky to have some strong industry experienced speakers come speak:
    • Michael Cote – Pivotal
    • JP Morgenthal – DXC.technology
    • Deepak Kulkarni – Charles Schwab & Co
    • Irakli Nadarishvilli and Mark Donovan – CapitalOne
    • Ryan Bagnulo – Guarden.io

    This is a great opportunity to come hear from early adopters and learn from their experiences.

    Register Now: http://www.innotechconferences.com/austin/about-2/microservices-day/

    Microservices Days, Austin – Agenda

    Time Presentation 
    8:00am
    9:30am – 10:15am
    10:20am – 11:05am
    jpmorgenthal
    11:10am – 12:00pm Deepak_Kulkarni

    12 Factors for the Enterprise

    12:00pm – 1:00pm Lunch and Expo
    1:00pm – 1:45pm Microservices_Irakli_MarkImplementing Microservices at Capital One
    2:30pm – 3:20pm TBA
    3:30pm – 4:20pm RyanBagnulo
    Microservices Maturity Matrix, Token Authentication & API Gateway Mediation

     Register Now: http://www.innotechconferences.com/austin/about-2/microservices-day/

    — JP Morgenthal