When an organization takes on an agile mindset, enterprise architecture doesn't go away, but the role of enterprise architects changes. Enterprise Architects no longer make choices, but help others make the right choice and then radiate that information. Enterprise Architects still need to form a vision, but then need to build bridges between teams to build communities of learning. These will allow teams to explore new approaches and learn from each other, with Enterprise Architects as partners in that growth.

To make fruitful use of technology, we need to align our technology thinking with underlying business plans. A technology strategy can drive this alignment, providing it properly integrates business and technology. We have developed a conceptual framework to help us with this strategic thinking, based on recognizing common aspects of strategic initiatives, leading us to identify eleven prevalent strategic directions. For each direction we outline the key business questions that they raise, and the investigations that we need to do to explore the technology implications. We've found that this framework leads not just to more effective technology strategies, but allows technology to inform business thinking, developing new revenue streams.

We, and our colleagues, are often called on to perform architectural assessments for our clients. When we do this, the architects involved with these systems will talk about the performance of these systems, how resilient they are to faults, and how they are designed to evolve to easily support new capabilities. The elephant that rarely comes up, however, is how different systems contribute to business value, and how this value interacts with these other architectural attributes.

Architecture need not be a monologue; delivered top-down from the minds and mouths of a centralised few. This article describes another way to do architecture; as a series of conversations, driven by a decentralised and empowering decision-making technique, and supported by four learning and alignment mechanisms: Decision Records, Advisory Forum, Team-sourced Principles, and a Technology Radar

Xapo was founded as a Bitcoin service provider and developed into an online bank. During this transition it needed to reassess its software estate and establish an architecture capability to guide its future. It took on ideas from Domain-Driven Design, Team Topologies, and the Architecture Advice Process to develop an Architectural Advice Forum. This led to greater alignment of its software delivery teams, and a coherent technology strategy.

Management love their metrics. The thinking goes something like this, "We need a number to measure how we’re doing. Numbers focus people and help us measure success." Whilst well intentioned, management by numbers unintuitively leads to problematic behavior and ultimately detracts from broader project and organizational goals. Metrics inherently aren’t a bad thing; just often, inappropriately used. This essay demonstrates many of the issues caused by management’s traditional use of metrics and offers an alternative to address these dysfunctions.

This is the second part of my keynote at OOP 2014 in Munich and is a tricky talk to describe. Usually I like a title and abstract to describe what the talk is about - but this talk is a journey, and I don't want to tell you where I'm going, but instead to explore the ground with me. I will say that it starts with my biggest problem with most adoption of agile software development - the nature of the interaction between users, analysts, and programmers. It goes on to explore these roles, raising questions about the relationship of programmers to users, our responsibilities to them, and finally the Two Great Challenges that I think programmers need to face up to.

Any reader of my writings will know that I'm a big proponent of evolutionary design. Despite my enthusiasm for this approach, no technique is perfect and I'm just as happy to report its problems as I am its successes.

Imagine a hiring situation. There's two candidates both with a few years of experience. In the blue corner we have someone with good broad design skills in the style of design that you favor (in my case that would be things like DRY, judicious use of patterns, TDD, communicative code etc, but the actual list isn't important - just that it's what you favor). However she knows nothing of the particular platform technology that you're using. In the red corner we have someone who has little knowledge (or interest) in those issues, but knows your platform really well - edge cases in the language, what libraries are available, fingers move naturally over the tools. Assume all else about them is equal (which it never is except for thought experiments like this) and that your team doesn't have any gaping holes that this candidate might fill. Which one would you prefer?