CONFERENCE PROGRAM

Please note:
On this site, there is only displayed the English speaking sessions of the OOP 2021 Digital. You can find all conference sessions, including the German speaking ones, here.

The times given in the conference program of OOP 2021 Digital correspond to Central European Time (CET).

By clicking on "VORTRAG MERKEN" within the lecture descriptions you can arrange your own schedule. You can view your schedule at any time using the icon in the upper right corner.

Track: Modern Enterprise Architecture

Sort by Tracks
Alle ausklappen
  • Tuesday
    09.02.
  • Thursday
    11.02.
14:00 - 14:45
Di 2.2
The Art of the Necessary
The Art of the Necessary

How much can you separate what you are building from how you are building it? This becomes an increasingly relevant question with IT moving from building systems to cultivating ecosystems. At the enterprise architecture level, one of the challenges nowadays is to decide which constraints to put in place to get a robust and evolvable landscape of interacting components, while at the same time it is important to minimize these constraints so that teams and units have some autonomy, and that the overall architecture can evolve continuously.

Target Audience: Interest in enterprise & software architecture and in digital transformation
Prerequisites: None
Level: Advanced

Extended Abstract:
In this presentation, we look at this interesting challenge from the standpoint of APIs, and how they can help to reduce the constraints to the necessary ones, while still resulting in an effective architecture.

One of the main challenges of enterprise architecture and software architecture today is to move from building systems to cultivating ecosystems. With business and IT moving closer together, and the demands on businesses to become better at changing and adapting, this introduces new constraints into architecture that looked different when the main goals were mostly centered around being secure, robust, and efficient.

Ecosystems exhibit different qualities from systems in the sense that they afford more autonomy to components, while at the same time introducing models of fitness and continuous change. With today's demand on business and IT to become faster and more effective at changing, the question is how to reflect those demands in new practices and models for architecting. We argue that one way of doing this is to focus on constraints, and to also focus on minimizing the constraints so that components can adapt and evolve as freely as possible.

We present a model of how to address API issues in the four areas of strategy, program, platform, and products. The goal of this model is to have as much coordination and alignment between these areas as necessary. The way this is done is by having clearly structured guidelines that represent and communicate the constraints, and that always clearly explain the rationale, the constraint itself, as well as possible ways how to comply with the constraint and how to test for compliance. The goal of this is to create loose coupling while still having a structure that allows governance. While in practice it would be ideal to fully automate all tests so that governance can be done in a full self-service model, so far we have concluded that automated testing is a good goal to have, but that some constraints still need a process of human review and approval.

Erik Wilde works in the Axway Catalyst team and focuses on API strategy, API programs, and API platforms. His main goal is to make sure that organizations make the right decisions when it comes to using APIs as the foundation of their digital transformation initiatives. Erik has a Ph.D. from ETH Zurich, is the author of many articles, papers, and books, is a frequent speaker at global API events, and contributes to standardization activities to help improving the way how APIs are designed, managed, and used.
Erik Wilde
Erik Wilde
Talk: Di 2.2
flag EVENT MERKEN
17:45 - 18:45
Di 2.4
You Can't Put a Price on Architecture? Then Please Don't Call It Architecture!
You Can't Put a Price on Architecture? Then Please Don't Call It Architecture!

Architecture work is all about trade-offs. We weigh security against ease of use, we balance availability with maintainability and contrast performance with reliability. But how do we evaluate the cost and benefits of change? As architecture is a means to an end, not an end in itself, architectural improvements have to be governed by sound reasoning, and more often than not that has to be based on numbers. Which in turn implies the need for good practices for the financial evaluation of technical decisions. Here we'll explore a dozen of these.

Target Audience: Software architects, developers, managers
Prerequisites: Some experience with real world architectural and design decision (even without putting numbers on them)
Level: Advanced

After quite a while in software development in the last century Michael Mahlberg turned to consulting on software architecture and processes in general around the turn of the Millennium. Always with a strong focus on continuous improvement and sustainable change he now spends most of his time supporting clients in their quest for more effective ways to work, mostly by applying lean and agile concepts.
Michael Mahlberg
Michael Mahlberg
Talk: Di 2.4
flag EVENT MERKEN
17:00 - 18:00
Do 2.4
From Capabilities to Services: Modelling for Business-IT Alignment
From Capabilities to Services: Modelling for Business-IT Alignment

Service-orientation seems to be in vogue again, this time dressed up as microservices. Many seem to get going with very little plan and thought, running the risk of sliding down the slippery slope towards distributed monoliths. Some experts try to encourage domain-driven design, but that may confuse even more. We crave more guidance. Maybe the classic business capability maps could help?

Target Audience:
Architects, developers
Prerequisites: Some experience with modularisation and enterprises
Level: Basic

Extended Abstract:
Service-orientation is still a surprisingly hard and complex endeavour after all these years and the risk of getting it wrong, potentially ending up with a distributed monolith with its devastating coupling, fragility, and cognitive nightmare, is still very real to many. Our industry is fairly immature and moves so fast that internalising acquired knowledge seems difficult and we often go through cycles of re-discovery of findings made decades ago. Maybe some SOA practitioners from the previous attempts made some breakthroughs that we have missed as we now have another go with microservices?

The concept of business capabilities from business architecture can be one approach to take a closer look at, with its holistic outside-in perspective of the company. The capability vantage point inherently abstracts away the 'what' a company does from the 'how', describing the essence of what the business offers. In this talk we will take a closer look at what they are and what they can help us with, all the way from business strategies and analysis, via organisational design to data management and technical design. They may just be the tool we need to design services, micro or not, holistically in a business aligned sociotechnical system, where people, information, processes, and technology defined by the business capability they support.

Trond Hjorteland is an IT architect and aspiring sociotechnical systems designer from the consulting firm Scienta.no and has many years experience with large, complex, and business critical systems, primarily as a developer and architect on middleware and backend applications. His main interests are service-orientation, domain-driven design, event-driven architectures, and sociotechnical systems, working in industries like telecom, media, TV, and public sector. Mantra: Great products emerge from collaborative design.
Trond Hjorteland
Trond Hjorteland
Talk: Do 2.4
flag EVENT MERKEN

back