By Patrice Kerremans, Stéphane Campo, Jan Casteels, Jean François Declercq, Kristof Dierckxsens, Bart Du Bois – XPLUS Consulting
As enterprise architects, we are so often confronted with this question:
How can we embed an agile way of working into our practice? Or even in a waterfall/agile hybrid?
We’re not here to write another article about roles and responsibilities – these are defined by the different methodologies. We’re not here for a high-level vision, either. We’re here to share our pragmatic observations and thoughts about the role of an Enterprise Architect within an agile context.
Admittedly, we sometimes feel lost in a desert city full of straight shooters – the squad masters – with one esoteric sheriff, the tribe lead….
Figure 1 – Feeling lost in a desert city full of straight shooters – the squad masters – with one esoteric sheriff, the tribe lead….”
Hence we have classified our observations into three categories:
|the good (dos):||the bad (don’t):||the ugly (really don’t ):|
|1. Manage your architecture backlog
2. Deliver value incrementally
3. Be clear about Definition of Done
4. Distinguish Design Authority from Architecture board
5. Deliver architectural decisions continuously
6. Be clear about confusing role names
7. Be in control of the big picture
|1. Write monolithic architecture documents that nobody reads
2. Focus too much on the target
|1. Become the blocking factor
2. Ignore the daily life of the squad
We do not pretend to be exhaustive, and welcome any observations to enrichen the debate.
Adding, adjusting, grooming, and prioritizing architectural work items on an architecture backlog has been elaborated by Eltjo Poort  and Gerben Wierda  . In essence it’s about considering architectural decisions as deliverables in themselves.
Figure 2 – Gerben Wierda’s Enterprise Chess style of managing Architecture Backlog and Solution Backlog 
For these decisions we should be able to build a decision plan: Without this decision, at that time, we’ll start getting into trouble…
Architects must follow and contribute to the increment, whilst also being able to position this increment in the overall vision. Hence we need to excel in delivering the narrative about the relation between the current increment and the overall delivery scope.
Figure 3 – incremental value delivery – from Henrik Kniberg’s article 
Endless deliveries are difficult to follow. In agile, it’s tempting and dangerous to end up with an unclear definition of done and therefore everlasting architecture tracks. At key points in the delivery process, architecture governance should contribute to measure and visualize potential deviations.
Figure 4 – checking for course deviations
Enterprise architecture is a relatively young discipline with tangible variations across organizations. We often confuse the level of granularity, mistaking architectural decisions as design decisions or vice versa.
By clearly separating the design authority function from the architectural decision, we enforce the right level of decision to the appropriate audience/board, avoiding useless meetings for a tribe lead or frustration at the squad master level. The right decision, at the right place.
Figure 5 – Distinguishing between architecture and design
How do we present a complete vision when we want to be iterative? At first glance it seems schizophrenic. It’s not. A vision must be made, with acceptable levels of risk and assumptions. Clarify iterations and validate or invalidate these assumptions.
Experienced architects will limit failed iterations but, by definition, we should be realistic and accept that also at the level of enterprise architecture we will make failures.
Figure 6 – Fail fast, iterate and pivot 
We need to share terminology, also on roles and responsibilities. Be clear about confusing terms such as solution architect and feature architect, even if it’s not 100% backed by a strong theoretical background. We are not in avionics or core science. IT is one of the youngest and fastest changing industries, so nothing is written in stone. We must remain pragmatic and adapt to new situations.
Figure 7 – Roles are defined in context of other roles
EA is not dead – yet it needs more focus on business architecture and more focus on customer journeys. The enterprise architects of tomorrow must be more and more capable of talking with business.
Execution is gaining autonomy. Instead of fighting to preserve any prerogative, we should adapt and be in control of the big picture more than ever.
Figure 8 – sensemaking and storytelling as key qualities
Very detailed RFPs, documents of 50 or more pages or long lists of cryptic principles are a thing of the past. Instead, we have to try to work with one-pagers and references cards that are printable, readable, actionable and pragmatic for a broad audience. When a document is used, understood, shared and endorsed, it’s a win.
Figure 9 – Margaret Hamilton, lead software engineer of the Apollo Project, stands next to a huge stack of code written by her and her team, in 1969 .
Having a target is important, it’s a starting point. But the focus must be on stable intermediate steps. It’s typically far more difficult to achieve than we initially assumed.
The beauty of an architecture in IT is not to build a cathedral, but rather to build a tent and to turn it into a cathedral step by step (I can’t remember whose sentence this, but he or she deserves the credit 😉
Again, it’s impossible. Learn to control and mitigate risks instead.
Value is delivered through interactions between people. The same applies to delivering architecture value.
A good collaboration model between enterprise architects and solution architects is essential. This should include face-to-face sessions where architecturally significant observations can be introduced and/or bubble up.
Figure 10 – Two forms of the Architect as the navigator : (i) the cartographer mapping/guiding ; and (ii) the scout exploring. A good collaboration model between them is essential. 
Accept to work with identified risks and assumptions and measure the deviations over the time. Work with the limitations.
We have seen enterprise architects becoming the unique point of reference when it comes to integration, communication… In the beginning, such a role is rewarding but it turns into hell over time.
Try to explain the principles, the concepts and the big picture to ALL members. Their autonomy will save your life. A good enterprise architect distributes the information and makes sure everybody understands the rationale.
Attend the different ceremonies and participate. The ivory tower must be destroyed, now more than ever.
How to send your legacy applications on a well-deserved retirement?
In this series, several of our consultants will give their advises on one of the hottest market topic of the moment. How to manage legacy applications decommissioning?
When you are working as an IT consultant within established businesses / industries (as in my case, banking), you will have probably encountered a lot of legacy landscapes.
As a consultant we help the banks to enrol large transformation programs to be ready to serve the customer in a new Digital way.
The implementation of these programs is most of the time well organised (everyone in IT likes to work on challenging projects which make use of cutting edge technologies). However, one task is often forgotten, to get rid of the obsolete applications.
Nevertheless it is important that the Banks Business strategy and its evolution towards Digital is reflected in its application portfolio. And here the problem starts, the application portfolio of banks is often the result of decades of history with solutions to punctual problems, technology brought in to solve an immediate challenge, incomplete consolidation after M&A or corporate restructuring, change of legislation.
Management attention is set on new functionality which makes decommissioning a “deferrable” expense.
In order to (partially) solve this issue, we should make the projects / programs which deliver new solutions also accountable for the obsolete applications. These teams should take specific actions (i.e. lifecycle management update, reengineering, decommissioning, …) in order to put the legacy applications that they are replacing in retirement.
In order to obtain a good obsolescence rate, it also seems important that this work is done by a different team than the team that maintains the legacy.
A fresh view on the existing business / IT problem is often welcome. Nevertheless, it has taken IT decades to reach its current state, so we can assume that we will not be able to remedy all of this in a portfolio overnight.
The decommissioning exercise is a serious transformation initiative on its own.
Last week I spent a few hours talking with the Chief Architect Rudy Wouters ( ING Tech Chief architect for Market Leaders ).
Rudy answered a series of questions regarding Digital transformation and enterprise architecture.
We are happy to share his experience with you !
In one sentence, how would you describe what is a ‘digital transformation’?
[Wouters, R. (Rudy)] Digital transformation is happening to the daily life of everyone, i.e. activities like shopping, socialising, gaming, gambling, managing finances are now done online.
How would you describe your role as chief architect?
[Wouters, R. (Rudy)] As a chief architect, my mission is : “ To develop, advise on and execute the architecture policy, standards and strategy, in order to position adequate IT capabilities for realizing and enabling changing business needs and moving towards a globally scalable and secure banking platform.”
As part of this mission, we create an environment to continuously foster the professionalism of the architects. After all, stable and secure solutions are delivered by good professionals.
What are your daily difficulties?
[Wouters, R. (Rudy)] Finding the right balance and priorities. Dividing the attention between Horizon 1, 2 and 3 work, between planning and operational support, between less and more detail to deliver to the squads, between first time right and iterative improvements, between global and local solutions.
How do you see architects’ responsibilities evolving?
[Wouters, R. (Rudy)] ING is implementing globally a new and agile way of working. Predominantly this means that accountability and autonomy is given to multi-disciplinary squads. To get the full potential out of the squads, they need to be fed with sufficient context and boundaries, not with details. This means that although the purpose of the architects still remains the same, the service is delivered in a different way. In addition, architects will have to spend more time in structuring the portfolio well in advance and provide a view of how business outcomes can be realised across the different assets and thus teams. The latter requires a mature collaboration, between architects and tribe leads. Overall, communication competencies become more important than deep technical knowledge in specific technologies.
What is – from your point of view – the next innovation that will impact your activity?
[Wouters, R. (Rudy)] As the digital transformation advances, also within the bank, the business processes are moving towards full digitisation. E.g. some of the least expected ones a few years ago, are now picked up by robots. This means that, whatever happened within and often also outside the company, is available in exploitable data. Still today, humans interpret these data to take business decisions. More and more of these feedback loops will become automated, meaning that commercial and operational aspects of the business will adapt themselves to the reality created by the customers. This means that software engineers will focus more on smart algorithms and artificial intelligence to keep up with the required agility. Stand-ups will be more organised around screens showing how systems are currently running the business, trying to understand why this is happening and consequently maybe steer the responses in a different direction.
What is the current digitalization challenge of your company today?
[Wouters, R. (Rudy)] We still have difficulties to benefit from our size, i.e. it is a challenge to work towards globalized solutions, that are being used many times. Mainly this is coming from the different speeds of the business in different parts of the world and leads to differences in priority. Eventually, the speed of change is limited by the amount of engineers that can be put to work in an effective manner.
Which transformation project is the most risky from your point of view?
[Wouters, R. (Rudy)] To be really competitive in a digitalised world, also the core systems of the bank must be adapted to more real-time and data driven processing. As this happens in flight, it is risky for many reasons: because they are part of nearly all business flows, there is a real danger of jeopardising stability and continuity of the business, at the same time, there is only in the long run additional value visible, which increases the risk of losing focus leading inevitably to failure to deliver.
Which transformation project will bring you the most value?
[Wouters, R. (Rudy)] In terms of potential, it will most probably be situated around the core systems upgrade, in terms of immediate value it will be related to how we change our means for integration in to the ecosystem.
Explain the risk of omission of EA, in other words, what happens when it is not present?
[Wouters, R. (Rudy)] Every company with a sizable change portfolio has had this experience already several times. Without the structuring capabilities of EA, it is very difficult for executives to have sufficient overview to determine a strategy that is not disconnected from reality. Defining a target view may still be easy enough, but when sufficient structured information down to the operational level is missing, it is impossible to define executable steps that lead to that target or even understand that the target cannot be achieved, inevitably not leading to the desired outcomes.
How do you communicate the value of architecture to your CIO and other Cxo’s?
[Wouters, R. (Rudy)] Talking or reading about it will not do the trick. If that would be true, everyone would be convinced. There is enough lecture on the subject to fill a room. According to me, the difference can be made by the actions of the architects at all layers of the company, from operational to tactical to strategic activities. The architects should always prioritize their activities towards complementing the value of the teams and ensuring stability of the solutions. This added value finds its source in the structured oversight they have and their understanding of how everything relates to the desired outcomes. Architects with this behavior will be communicated about.
Which book recently influenced you ?
[Wouters, R. (Rudy)] There are actually two:
1/ “reinventing organisations” from Frederic Laloux
2/ “Continuous Architecture, sustainable architecture in an agile and cloud-centric world” from Murat Erder and Pierre Pureur
How do you see the challenge of training, keeping your architects?
Given the importance for architects of context and integration with the organisation, there is added value in a stable architecture workforce. How can architects then be convinced to stay with the company while satisfying their desire for new challenges. For this reason, we’re working in a partnership with XPlus on a true architecture training platform. The idea is to allow companies to produce and consume interesting training, dedicated to architects. At the same time, there is an opportunity to bring together architects from non-competing industries, in classical training. When brought together, being presented with similar challenges, they may exchange valuable information with each other but even more, they may ignite new ideas for collaboration across companies. The main idea is to enable companies to create their own architects – you don’t hire an architect, you create one. On the other side, it allows architects to find diversity in their work, without having to switch company.
By Patrice Kerremans
What is it?
The official definition from the W3C Credentials Community Group is: A statement made by an entity about a subject; A verifiable claim is a claim that is effectively tamper-proof and whose authorship can be cryptographically verified. Multiple claims may be bundled together into a set of claims.
The (somewhat unspoken) fact is that claims can be distributed and do not require a centralized system, because their verification is a matter of cryptographically verifying them. That is, you don’t need a central server to be up-and-running and accessible at all times for you to be able to verify the claim. This makes the system very sturdy.
Also, the creation of claims is delegated to the issuers, making it even a more distributed system. What is it good for?
Other interesting examples include: proving you’re old enough to (buy a) drink, proving you have the required driver’s license when renting a car.
There’s a complete description of the use cases on the W3C github.
Who are the actors/players?
In order for this to work, you’ll need the following actors:
An entity that creates a verifiable claim, associates it with a particular subject, and transmits it to a holder. This can be -for example-
a bank (certifying account ownership), or
a doctor (certifying that you have a certain ailment), or
a government certifying your identity or your birth certificate
a school certifying you’ve successfully achieved a certain degree
An entity that is in control of one or more verifiable claims. This is typically the subject of the claims. But it can also be a third party that holds on to the claims on behalf of the subject.
A statement made by an entity about a subject and that is tamper-proof and whose authorship can be cryptographically verified. This means that
when someone fiddles with a claim, this can be detected; rendering the claim useless
but also that when someone tries to counterfeit one this is detectable; also rendering the claim useless
Say that you create a claim that you’ve obtained a degree at the University of Ghent (UoG). Since the claim won’t have been signed with the private (& secret) key of the UoG, the claims digital signature will be incorrect and others will detect this.
An entity that receives one or more verifiable claims for processing. Examples of inspector-verifiers include employers, security personnel, car rental services, and websites.
Mediates the creation and verification of subject identifiers. Examples of identifier registries include corporate employee databases, government ID databases, and distributed ledgers.
In the next post we’ll go into how to implement this…
By Frédéric Crabbe & Hans Dijckmans
This is a novel which tries to explain the underlying story of how an organisation can go into crisis because IT and software development form a bottleneck for the business. What I like about this book is that it looks at an IT transformation via DevOps (or agile, or any other buzzword you prefer) and is gradually showing the relevance of IT in the enterprise and how interconnected everything is that makes the business run. So calling this a DevOps book is an understatement. The book takes a broad view of DevOps and shows how it can be used as a way to integrate IT into the business rather than being an under-performing cost-centre (the way business often looks at IT). The underlying idea is to take the lean methodologies from manufacturing, and bring them to IT. It also shows that by promoting system thinking (over local optimization), feedback loops and a continuous learning culture. Of course, automation and continuous delivery are necessary intermediate steps for most traditional IT organisations on that journey.
The book tells the story of an IT department manager Bill Palmer, being promoted against his will to Vice-President (VP) of IT Operations within the company Parts Unlimited, a manufacturing and retail company. Parts Unlimited is losing market share quickly and is very much dependent on the successful implementation of a strategic project called the “Phoenix project”. But before critical IT resources within the company can focus on that project, there is a lot of other “IT pain” to be resolved. The book describes Bill’s journey in facing these IT challenges, ultimately giving the IT department a new and positive image within the company. As the book is written in novel style, it offers an entertaining story line and tons of deja-vu moments for most of us. The book is overall relatively realistic in its description of difficulties that IT organisations are facing, but the multitude of problems might be a little more than what you will find in one single IT organisation. Nonetheless, the book is very good in its initial objective, which is to apply the theory of constraints to IT and in showing that IT isn’t that much different from manufacturing. In addition, the added-value of ITIL and DevOps are demonstrated. Organisational anti-patterns that commonly impede business and IT cooperation are nicely described. It outlines you ways to escape the vicious circle by keeping things simple, building trust, making objective observations and trying out new approaches.
By Patrice Kerremans
I’ve always had the impression that the microservices movement was trying nothing more than to apply SOA with common sense. Meaning, applying SOA without going overboard with tooling, for instance. And without the militaristic top-down approach. Etc. Martin Fowler put it much more eloquently in his talk during the goto; conference early last year.
And what I did appreciate most in his talk, was his comparison between a monolithic and a microservices approach:
Monoliths have the advantage of supporting: simplicity, consistency, inter-module refactoring
Microservices on the other hand favorably support: partial deploying, high-availability, preserving modularity, multiple platforms.
Just by looking at the advantages of both, it seems almost obvious that one should start by implementing monoliths. Only when it becomes really painful should one start thinking about chopping the monolith up into microservices. Now, if you do properly modularize your monolith and keep it nicely modularized just up to the moment in time where you need to start chopping, moving from a monolith to a microservices architecture should be doable in a short amount of time. So please, after going overboard on SOA, let’s not go overboard on Microservices. Of course, if the past is an indication for the future, five years from now, we’ll probably start applying microservices with common sense (I wonder how we will call it then ? )
By Frédéric Crabbe
It is strange to think that we spend more time on a daily basis with the people we work with than our own family and friends. When spending so much time at work, it makes sense to invest quite some time in strengthening our relationships with our co-workers. Instead of spending time and energy overcoming the problems associated with negative relationships, we should instead focus on making our work more enjoyable by having good relationships with those around us. By making the effort to get to know the people with whom you work and learn about what skills and abilities they bring to the table, you will be able to build some nice work relationships. These work relationships form often the cornerstone of success and satisfaction within your job and career. Also, people are more likely to go along with decisions that you want to take. Overall, I think we all want to work with people we’re on good terms with. So, building and maintaining good relations with our co-workers sounds like a good plan to me.
By Frédéric Crabbe
Conway’s law states that you cannot design architectures that differ much from the organisation’s communication’s structure. Since a few years, organisations have understood this link between organisational structure and the software they create, and are searching for solutions.
Some organisations are embracing new structures in order to achieve the outcome they want. Organisations in which I worked were pursuing an agile transformation. Instead of delegating tasks to employees, they wanted to create ownership by delegating responsibility (creation of self-organised & self-managed teams). In order to make such stories successful, you first need to have the power the ability to actually perform such a change in way of working. And secondly, you must introduce the appropriate constraints (taking into account the strategic business priority and the necessary governance structures).
The other way around is also possible and organisations are more and more investing in certain technologies like Microservices. Classic monolithic developed applications are no longer sufficient as they become too complex and expensive over time to evolve and changes require progressively longer development time. A microservice approach where functionality is developed and deployed independently (within well-defined boundaries) allows organisations much more flexibility in aligning the architecture of their systems to the structure of their teams in order to ensure that Conway’s law is redeemed.