Downloaded 20 times
Uploaded byLiz Keogh
Organic, not chaotic
Organic, not Chaotic: How to grow your Architecture provides strategies for developing architecture in an organic way to avoid chaos. It suggests having architects, developers, and testers work together using deliberate discovery skills to reduce rework. Architects should create strategic plans and test architectural constraints while developers address tactical problems to evolve new plans together. Options should only be committed to if there is an understanding of their value and expiration. Communication and collaboration between roles is key to growing architecture successfully.
Organic, not chaotic
- 1. Organic, not Chaotic: How togrow your Architecture Liz Keogh liz@lunivore.com @lunivore
- 9. Manager Architect Architect Dev Dev Dev
- 10. Analysis Dev Test Release
- 14. Options have value. Options expire. Never commit early unless you know why.
- 19.
- 21. Rework Developers Testers Deliberate Discovery skills
- 22. Less Rework Testers Developers Testers Deliberate Discovery skills
- 23. Rework Architects Developers Architects Strategic Tactical New plans constraints plans
- 24. Less Rework Architects Developers Architects Architectural “tests”
- 25. In order toachieve a goal As the stakeholder I want some stuff.
- 26. In order toreduce security operations costs As the VP of operations I want users to use our single sign on.
- 29. Or, how dowe know when we’re done?
- 41. 1 1 1 2 2 2 3 3 3
- 42. 1 1 1 2 2 3 3
- 43.
- 44. $$$$$$$$ $$$$$$$$ $$$$$$$$ Shipped (1 year) $$$$$ $$$$$ $$ Deadline $$ Not Shipped $$
- 45. $$$$$$$$ Shipped (2 months) $$$$$$$$ $$$$$$$$ Not Shipped $$$$$ $$$$$ $$ Shipped (2 months) $$ Not Shipped $$
- 57.
- 58. “Managing the DesignFactory”, Don Reinertsen “Waltzing with Bears”, Tom de Marco and Timothy Lister “Domain Driven Design”, Eric Evans
Editor's Notes
- #3 Architects have the responsibility to ensure that the Enterprise can continue to deliver compatible software over long periods of time. Often they don’t code the frameworks or tools they use to ensure this, or if they do, development teams often don’t use them.Developers have the responsibility to deliver their particular project. Often teams of developers are asked to work weekends and overtime if it looks like they might not deliver. Devs are under pressure to get something working and out of the door, now, and rarely have time to help an Architecture team solve their larger, longer-term problem.
- #4 We’ve been talking about incremental and Agile architecture for years. There are thousands of papers and blogs on the subject. So why doesn’t it work?
- #7 The teams have radically conflicting goals!
- #8 The teams are rewarded for meeting those goals – and not for meeting the other team’s!
- #9 Each project is usually funded by some particular part of the business. No single department wants to pay to ensure that they can work effectively with other departments! So nobody pays for this or budgets for it. Paying the architecture team isn’t enough, because this has to be done as part of every delivered system and feature.
- #10 Architects are still seen as hierarchically “above” software developers. Architects tell developers what to do, and developers do it (except they don’t’).
- #11 Meanwhile, Lean and Agile are helping to create whole teams which work together to deliver something to the business. Because the traditional hierarchies are disappearing, Architects can no longer tell developers to “just do it”.
- #12 Another problem is that by the time the architects have decided on the architecture they’d like, the development projects are often already underway. And when the architects tell the developers what to do, the developers tell them why that won’t work. In traditional software development, teams tried to make sure they got it right before they started work. Nowadays we know we can’t get everything right up front, so the development teams are assuming that some of what they do, at least, will be wrong. But are the Architects doing anything differently?
- #13 Agile methodologies take advantage of fast feedback loops to get developers the learning they need to adapt to the things they find out are wrong. That’s great, except that how will you know architecture is working until a couple of systems are both built on top of it? Architectural feedback is by its nature pretty slow.Lean methodologies, however, ask us to look at the whole value chain – the production of software from beginning to end – and to make that whole value chain quicker. It does this by finding the slow feedback loops and making them faster (because software development is more like product development than a production line). So how can we make architecture faster?
- #14 Once enterprise architecture is in place it’s really hard to change, compared to application software. It represents a significant commitment…
- #15 … and you know how much I love Real Options, right? I hate commitments. As a developer, I have enough problem with the commitments I made just trying to implement an application, let alone take on board an entire enterprise! I don’t want to do that.(For those people new to Real Options, my favourite example is the Brickell Key awards at LSSC 2011. David Anderson and a bunch of valuable consultants had to get together to vote for 2 out of a shortlist of 6 nominees to win the award. The only time the consultants could get together was Tuesday, the day before the conference. The announcements for winners were going to be made on the Thursday. The lead time for getting the crystal trophies engraved was 4 weeks!So, David Anderson paid to get 6 trophies cut. It cost $500 extra; a lot less than the day rates of all the consultants. That’s Real Options thinking!)
- #16 Imagine a project that you did recently – something reasonably chunky. How long would it take to do the same project again, with the same people, same technology and same requirements – just again?Many people think that it will take 20 – 40% less.
- #17 This is because the team have already learnt what it is they need to do. They’ve discovered all the “gotchas”, small and large, have talked to the business to understand the requirements, and they can go faster as a result.
- #18 Any project without risks has already been done by the same team before, so why are you doing it again? There’s always some differentiator for each project; something which makes it unlike the projects which have gone before.
- #19 The newer the components of a project are, the more uncertainty it will have. Keeping options open is a good practice in those situations.
- #20 This.
- #23 In BDD, we put the testers first with their evil Deliberate Discovery skills that always break my code. Aha! Now I *know* where the gotchas are going to be – at least, the ones they can tell me about – so I’ll code better quality work so that we don’t run into that problem. At least not so much.
- #24 We can do this process for anyone who traditionally takes on a gatekeeping role, even architects! Traditionally, architects are always adjusting their plans for the work that’s already been done.
- #25 What if we could define “tests” that allow the developers to know whether their software will help the architects or not?
- #26 This is a different version of the “As a… I want… So that…” template that Mike Cohn uses a lot and which came from the Connextra guys in London. Mike Cohn has said in the past that the “so that” is optional. I don’t believe it is. I like to put it first. Now we know what it is we’re trying to achieve.
- #27 In any organisation, there are multiple stakeholders – not just users. In this instance, we show the VP of operations and his goals. Now we have a mechanism for juggling the needs of multiple stakeholders and making them apparent to others! They’re not user stories! http://lizkeogh.com/2010/02/02/theyre-not-user-stories/
- #28 If all stories were aimed at users, we’d get rid of CAPTCHAs for a start. “As a user, I want a CAPTCHA so that… wait, no, I don’t!” We’d also get rid of ads. So who are the architectural stakeholders?
- #30 The rules which apply to good application scenarios or tests also apply to architectural ones.
- #31 This is the template which we normally use for BDD. Let’s look at this from an architectural POV.
- #32 Here’s a scenario. Notice that this doesn’t really talk about the benefit of single-sign-on, or say how you’re going to do it. But it acts as a test to see if it’s working, and helps the developers understand what’s needed.
- #33 This is a question I like to ask when I’m picking up a scenario for the first time.
- #34 Oh, yes. Some people don’t have access to all the systems, so they should be refused access.
- #35 This is the second question I like to ask. I like talking about pixies because then it gets people’s heads out of the software. Think about a message bus. If it were pixies carrying the messages, why would that be useful? What do the pixies achieve?
- #36 Oh, we also need to log access for auditing requirements – the legal guys want it. (There’s another stakeholder.)
- #37 It’s much more important to have the conversations around these things than it is to write them down, and more important to write them down than to design automated tests around them. Having said that, you might want to write performance tests, run security pen tests, etc. – and it’s OK to do it without the Given, When, Then format.
- #38 In any architecturally complex system, the feature we’re building will only need part of that system. By building just enough for the feature, we can get information about whether our chosen architecture will suit our stakeholders’ needs while leaving our options open elsewhere in the system for the future.
- #39 We code just enough of the architecture to get our feature working.
- #41 Here’s how we’ve traditionally done software. We take a big bucket of requirements…
- #42 We divide it into milestones…
- #43 And then because we’re doing Scrum, we turn it on its side and split it up a bit finer…
- #44 …then we call it a backlog. How is this any different from Waterfall?
- #45 We normally do this because we think that a deadline is the risky part of the project. I find a lot of deadlines are purely political anyway. I don’t know about you, but I hate working weekends and evenings just so a PM can look cool because they got their project in “on time”!
- #46 What if there was some aspect of the project that was differentiating? How little could we get away with doing just to get that one differentiating feature out of the door? Now we’re making money earlier, and if it turns out that our feature is too hard or it doesn’t rock the market, we haven’t invested huge amounts of money.
- #47 This is a great book on just that.
- #48 So let’s say that there’s one risky component in our architecture. One thing that we don’t know whether it’s going to work or be performant, etc. Do we really need to do all the other bits of architecture in order to check that one piece?
- #49 In some situations, I’ve hard-coded the data directly into the app, just so that I can test some other part of it – like connecting to a legacy application, or testing message bus performance, etc. Getting data out of a database isn’t risky. We can always do that later! But now, I’ve left my options open to change that architecture too – so maybe I don’t have to get the data from a database after all!
- #50 Sometimes we want to pay a bit extra to keep our options open. We need to gather audit information in case an audit is required. We need to capture customers’ email addresses – we don’t actually have anything to send them yet, but it seems like a nice option to have. Data integrity is basically about having options in the future, so it’s worth considering what optional data we might need.
- #52 Dear Architects, if you’re writing a shared library for me to use, please keep it small and focused on my needs. If you start trying to wedge my needs and everyone else’s into a huge monstrosity of a library that suits everyone, you’ll find I’m using your library *and* going around it too. If you write one just for me, then write one just for me and the team next door, then grow it, it stands a better chance of having a nice clean usable interface and being suitable for real business requirements.
- #53 I once talked to a manager in a company which had bought four other companies. Each one did something unique and special, which was why they had bought them. By trying to make all the four companies integrate their software in the same way, the purchasing company was about to make each of these others lose its differentiator – the valuable stuff!
- #54 Eric Evans refers to the differentiator as the “core domain”.
- #55 Eric Evans uses the concept of a cargo shipping company. If you ask the shipping department, cargo has height, weight, fragility, etc. If you ask the accounts department, cargo has a price, a customer and a billing date. If you ask the logistics guys, it has five legs, one of which is by sea. If you ask the legal department they’ll tell you who’s insuring it and at which point ownership changes. They each have some information they need to share, but they don’t need to speak each other’s languages – just a bit of each other’s languages. A translator between each of these “bounded contexts” may be faster to code and more maintainable than a huge data dictionary!
- #57 The best approach for an architecture team is to get stuck in there. Go sit with the teams, ask them what’s easy and what’s hard, help them code and become part of the team yourself.