Are traditional architecture engagement models still relevant?

An article I wrote, originally posted on the Davanti Consulting website, 30th November 2016, reposted here with permission.

Reinvention dominates the business landscape, pervading how we work and how we engage with those around us. As an architect, I sometimes wonder how many of my industry colleagues have noticed this and contemplated similar innovation. As architects we are often perceived as dinosaurs; surely then, the time to start reintegrating ourselves is now.

THE CURRENT STATE OF ARCHITECTURAL ENGAGEMENT

A good architect can bring excellent value, but that value is lost if it arrives too late. Some of the barriers to this value even appear to be systemic or stem from entrenched legacy thinking.

The way in which architects engage is influenced by several factors, including:

  • Control: architectural governance is often perceived as regulatory rather than wisdom.
  • Processes: these are often complex, “heavy”, unwieldy and time-consuming.
  • Resourcing: architectural capability is often scarce, a scarcity which is exacerbated by heavy processes.

Traditional architectural engagement tends to be based on a “these are the rules” approach renown for volumes of documentation and thinking before any real work starts. Interestingly this way of working doesn’t really have a name – it “just is”. There’s definitely a number of architects who got the Agile memo, but overall that percentage is still relatively small.

There are architecture frameworks such as TOGAF, but a framework is not an engagement model. TOGAF has the “Request for Architecture Work” concept, but this is more of a one-shot form. TOGAF is aimed at enterprise architecture and whilst it refers to solution architecture it does not attempt to address how architects should engage with stakeholders in a product or project delivery setting.

At the project level, architectural engagement will ideally be in the form of an embedded solution architect. Ideally their engagement will start with the business case and continue through to overseeing the implementation. At worst, their involvement will be sporadic or non-existent. For various reasons such as a scarcity of architects, coupled with the weightiness of architecture processes, this engagement will likely be forgone for smaller projects. The associated risk is that smaller projects often grow into bigger ones, consequently attracting belated architectural attention.

So, short of everyone drinking the agile Kool-Aid what should we do? What might a revamped engagement model look like? How do we start, and what are the challenges we need to solve?

FUTURE STATE

The goal is to ensure that architects are able to add value in a timely and sustainable manner.

As architects often work as part of an architectural practice, and within the boundaries of architectural governance, both the architecture practice and governance may need to be revamped:

  • The architecture practice should reinforce behaviours and processes that make the team more consistent in their approach, allows them to support each other, and thus positions the team to offer a more consistent experience to their business clients.
  • Ideally architectural governance should support the team in this change as they are its ambassadors. Governance should not be about doing architecture for the benefit of the architect.

At a high level, think about making these changes so that the following value is unlocked:

Do this 

 So that

Revamp governance.
  • It provides supportive guidance, rather than be a place where things go to be vetoed.
  • It is easy and relatively painless to use, and therefore gets used more often.
Create a toolbox of processes, tools & artefacts that is accessible.
  • Non-architects find it easier to understand and use, as a result the architects will need to spend explaining it.
  • More time can be devoted unlocking value and less time given to discussing the process.
  • Architects have the time (and opportunity) to spend engaging more broadly and more regularly with the business.
Encourage architectural mentoring and coaching.
  •  Architects can be seen more as collaborators and supporters.

 

REVAMPING GOVERNANCE

This isn’t a wholesale re-write, but more of a health check and possible diet.  You might be familiar with the concept of a good value proposition being one that your grandmother could understand; check your architectural governance processes and make sure they can pass that test. Make sure that what is expected is very clear, not onerous, and that its business value is self-evident.

CREATE A TOOLBOX OF PROCESSES, TOOLS & ARTEFACTS THAT IS ACCESSIBLE

Empowering the business, whilst keeping them and the architect team aligned, is going to mean having some supporting materials available. These will work with the revamped governance and be very practical in nature. In situations where architects are working with the business in a mentoring context they will need materials that they can refer the business too, and which the business can use with a degree of self-reliance. These materials should outline:

  • Technology constraints that are deemed important, and why. If possible, a sense of direction, as business and architecture are seldom static.
  • What questions to ask themselves, and when, so that the business doesn’t paint themselves into a corner.
  • Areas of danger or concern; things they should escalate to the architect so that they can be appropriately supported. Thinking along the lines of RACI can be helpful – for example: when should they inform and when should they consult.

These material might be pre-written guides, checklists and (lightweight) documentation and diagrams, or, checklists that the business progressively complete with varying degrees of assistance from an architect. They might be anything from risk assessments, solution option assessments to solution architecture definitions.

Creating materials that effectively support the business (and the architects) means creating materials that are easy to access – not just in terms of being easily located, but also easy to read, and understand.Materials should be suitably light-weight, so that they are easy to consume and keep up to date. After all there’s no point freeing up an architect’s time just to write more documents.

In terms of the artefacts you expect the business/projects to deliver, ask yourself “who will read the documents”? If the answer is “only other architects” then exactly what value does it provide and is it really necessary?

ENCOURAGE MENTORING AND COACHING

There will always be a need for architects to do the architecture, and to be deeply embedded in a given project; but conversely there are many opportunities where a lighter touch may be equally effective.

Coming to the business with a mentoring approach places everyone on a more equal footing, and increases the chance of a more meaningful collaboration. The architects are close enough to spot potential issues, establish some sort of rapport with the business and lead them where appropriate. The business is free to do some of the heavy lifting themselves, freeing up some of the architect’s time.

If successful, architectural value should become easier to unlock, and more valued by everyone.

ENGAGEMENT STYLE

So far we’ve focused on the engagement model, i.e. elements of structure, broad approach and the rationale behind it. Hand-in-glove with those concepts is the style of engagement, i.e. the communication style used and how you relate to stakeholders on a personal level.

It is vital that you tune-in to your audience. Architects need to be leaders, they need to manage stakeholders of all types, and in a range of different situations. To do this effectively will require you to adjust your engagement style to suit both the audience and the message.

The best laid plans are easily ruined by poor execution, and as good architecture is dependent on good communication it is essential to get this right.  Effective communication is a substantive topic in its own right, and beyond the scope of this article, but to get started, consider:

  • Being available, approachable and responsive.
  • Being good at active listening.
  • Being able to relate to others.
  • Being able to simplify the complex.
  • Being able to speak up.
  • Being good at asking questions.
  • Being effective at persuasion, mediation, facilitation.
  • How to say no without coming across as (or actually being) a roadblock.
  • Picking the right communication style for the audience.

IN CLOSING

As a discipline architecture offers great value, and architects tend to be clever people, but realising that value is not straightforward – as architects we need to be proactive, we need to be mindful of changing expectations as the world changes around us. Just because architecture deals in the fundamental does not mean it is impervious to change.

As practitioners of architecture, take what you can from new ways of working, such as Agile and collaborative tools.

Show the business and the rest of IT that architecture is not something up an ivory tower, and that we can lead innovation and change by example.

Architecturally Significant

“Architecturally significant” is a simple and useful concept that covers a few things…

It’s anything the architect (or anyone doing the architecture) needs to actively spend time and effort on.  It’s relatively more important, and getting it wrong would be “sub-optimal” – it won’t be easy to change and would have far-reaching consequences (e.g. costs and re-work).

Sometimes its about “picking your battles”.  Designing and developing solutions can be described as one long stream of decision making; in such a context the architect is going to be heavily involved in making these decisions, and sometimes the number of decisions that need to be made are more than they can easily handle – so picking the right ones is important.  (Putting aside for a moment the extremely valid point that decentralized decision making is a useful approach and so maybe the architect shouldn’t be the one making all of these decisions – at least not alone).

Working out when something is architecturally significant is a key part of an architects role (if you aren’t going to do it, not one else is), and given all too familiar time-pressures you’ll want to spend your time where it adds the most value.

randomwhiteboard001Confused?  Being able to “separate the wheat from the chaff” is a key skill for anyone performing the role of an architect.

Let’s take an example

Imagine you were talking with someone about what they needed, and they said:

  1. We need an online form that the user can fill in.
  2. The submit button needs to be red.
  3. The form needs to load in [x] seconds.
  4. As part of the form they need to upload a file.

Which of these is architecturally significant?

“We need an online form that the user can fill in”

The lesson here is that, like a lot of things, this is unlikely to be architecturally significant in of itself, but, hiding underneath this might be something which is significant.  It’s one of those situations where you just need to keep a watching brief on it in case something comes out of the wood work.

As always, context is critical.  If this is part of a solution where there is already an identified way of implementing forms, then it’s less likely to be architecturally significant as there is already a solution in place.  If this is a “first” for the project and there isn’t an identified way of implementing the form then it probably is architecturally significant.  How many forms are you building, one?  Probably not so significant; 50 – that sounds significant.

“The submit button needs to be red”

Aesthetics aren’t architecturally significant – red Ferrari’s might go really fast, but red doesn’t have the same implications for databases (yes, shocking, I know).

But there might be a wider need here, one that as an architect and thought-leader within the project you are well placed to raise: “Is using red for the submit button good from a usability perspective?  Isn’t there something about colour-blindness we should think about?  Who’s looking after usability anyway”?

Sometimes being an architect isn’t to solve all the problems, it’s to help identify the skills that you need.  “Yes, because this is a new 30 million dollar multi-region, multi-language e-commerce initiative we think having a usability lead is a good idea”.

“The form needs to load in [x] seconds”

In general terms, anything that involves System Quality Attributes¹ (SQA), i.e. the concepts that underpin non-functional requirements (NFR), should immediately receive the attention of the architect; they may not be architecturally significant, but NFR’s are usually one of the architects key areas of attention.

In this case is it architecturally significant?  It largely depends on what the value of X is, and how the architecture and infrastructure compares to that.

As a stake-in-the-ground, I suggest to you that the 80/20 rule applies: 80% of the time a new solution will meet the performance needs of most users, without needing any “special” performance enhancing work.  In such cases performance isn’t architecturally significant.  It’s often something that is discussed – but it’s not common (in my experience, i.e. in more than 20% of projects) that something “serious” needs to be done for performance reasons.  By all means keep an eye on it but don’t loose sleep over it.

When might it be architecturally significant?  If the value of X is especially high, you know the infrastructure is especially poor (slow, known to not meet the requirement), or if there are other functional or computational factors which are out of the ordinary – then yes, it might be architecturally significant.

Don’t forget that you can always push-back: “yes we understand the performance targets you want to hit, but are you aware it looks like it may cost between $x-y,000,000”?

“As part of the form they need to upload a file”

This is an interesting one, for which I have a real-world example.  So before we continue, do you think this sounds architecturally significant?²  After all, handling file uploads is nothing new these days.

For this project:

  1. We were using a COTS package which allowed users to upload files.
  2. The client was relatively large organisation and successfully managed their own infrastructure.
  3. Internal policy required all files coming into the organisation to be virus-scanned.
  4. Their infrastructure included a server-based anti-virus solution that was used to verify email attachments going through the email server(s).

Unfortunately, whilst the anti-virus solution had no problems scanning attachments in the email flow it wasn’t able to scan the files being uploaded through the application – as these were embedded in a custom application web-service call from the client back to the service layer, and got inserted into the application database as a blob, and not as a separate file that the scanning solution could read.  And as strange as it might seem, yes we were the first project where web-based file uploading was a thing.

Without doubt, this scenario is of architectural significance.

For a start, what’s going to happen if we are unable to scan the embedded files?  Will functionality be disabled, affecting users?  Or will the entire solution scrapped for one that can? (not likely after >18 months work & associated costs).

Can we get dispensation to just not apply anti-virus scanning?  If so, the architect will be leading those discussions from the projects point of view, probably taking it to the relevant design authority, and documenting the decision(s).

In scenarios like this there’s often no immediately obvious “slam-dunk” technical solution, instead there’s probably going to be a number of technical solutions – all with trade-offs and implications that need to be considered (i.e. “it depends”).

There’s also the non-technical / “business” angle to consider.  If the business/client/users are happy to change the way they do things this can open up new technical solutions, or make existing ones more viable.  Remember that bending the business to meet technology half-way is not always a bad thing, the more aligned the two are the better the end result usually is.

To briefly expand on the technical options, in this case we could change the way the COTS package works and obtain a new module for the existing anti-virus solution so that it can be called by the COTS API.  But even then there’s still a raft of technical options and detail to work through (starting with a proof-of-concept would be wise), and not forgetting we’d also need to convince the COTS vendor that they should change their product and the client that they need (and pay for) this new component.

In situations like this “architecturally significant” takes on new meaning as we’re now impacting the wider organisational architecture – not just the projects.  This is not a totally uncommon thing to happen – in larger organisations change affecting the wider organisation can come from within individual projects, as they are often the ones driving new needs and capabilities.

So to close

  1. Constantly be on the look-out for the things that matter.
  2. Focus your time and effort accordingly.
  3. Keep a watching-brief on things which seem innocent now but could be significant later or if circumstances change.

 

Footnotes:

  1. An SQA is a way of describing, defining and thinking about a solution.  Examples of SQA’s include performance, security, maintainability and so on (aka the “illities”).  SQA’s are not NFR’s, just as “Performance” is not a NFR on it’s own: an NFR is testable.  SQA’s are the basis for NFR’s – but they aren’t the same thing.
  2. If you said ‘no’, you’re wrong, if fact if you said ‘yes’ you’re also wrong.  Based on that much information (i.e. no where near enough) the correct response is something along the lines of “it depends”.  Once you learn to prefix any response to any question with “it depends” you are half-way to being an architect (yes that’s only partially serious).  Whether the rest of your subsequent response is actually helpful or not remains to be seen.

Career Progression into Architecture

In terms of career progression into architecture, people typically start off from one of several common “starting positions”. For example, a solution architect or application architect this is likely to come from a software development background.
Here a map of some of the more common paths:

typical-career-progressionThere are more types of architect and pathways than what’s depicted here, but based on conversations with architects I have met (or interviewed) this is a fairly accurate summary of some of the more common paths.

The Architectural Role Meta-Model

For simplicity, I define it in three parts (outlined below). In broad terms, Enterprise and Solution architecture disciplines cover the full range of domains but operate within a specific level of abstraction; whereas Domain architects cover all levels of abstraction but within a specific domain.  An in-depth write up on this can be found here, but in summary:

  1. Enterprise Architects – who typically operate at the highest level of architectural abstraction and across a broad range of domains.
  2. Solution Architects – who typically operate at a project or programme level. Although solution architecture covers the full breadth of domains, an individual solution architect will typically be relatively narrow in their focus – either providing general technical leadership within the scope of a specific project, technology or domain.
  3. Domain Architects – typically operate simultaneously across the spectrum of enterprise and solution architecture, but within a single specific domain. They will support both enterprise and solution/delivery specific needs.

Progression

We typically see common paths into and through architecture, such as the software developer into the application or solution architecture space; business analysis into the business architecture space, and so on.  Once in the architecture space it is possible to side-step into related roles – this might be done as a conscious and fundamental career choice, or may simply represent shorter-term variety driven by the work available.
The progression from solution architecture to domain architect to enterprise architect is common but by no means the only career path.

To a certain extent there’s a drift upwards in terms of abstraction (developer to solution architect; solution architect to domain or enterprise architect), but this isn’t always strictly the case.  It’s fair to say that each role has a set of skills and a temperament that suit it – some people will mature from one role into the next, others will take an alternate path.

The Product Specialist

One of the assumptions behind the solution, domain and enterprise architect roles is that these people often have a breadth of experience that goes beyond a single product or technology stack.  In other words, their careers are not defined along narrow vendor specific lines.  This is largely borne out by what I have seen in the market in terms of the experience people have and the career paths they have taken.

Such specialists will be genuinely skilled at what they do but lacking breadth of vision and depth of understanding that someone with a more diverse background is likely to have.

Is this good or bad?  Well I think that depends on what you need for the problem at hand; sometimes you need a very specialized tool for a very special problem, whilst other-times a more flexible tool is best.

One thing to be sure of though, as the technology market grows in breadth and diversity, areas of specialization will deepen.  As anyone familiar with web development in the early 2000’s can tell you, the number of stacks and architectures available has grown considerably; as that range increases so does the potential for individuals to specialize; so does the possible combinations of skills a specific job description might call for.

This specialization is reflected in the vendor space where larger vendors have their own subset of roles (think marketecture) that mirror the role hierarchies found in the general market. We therefore have product specialist roles starting to emerge, with people operating at the level of a solution architect but with a background that cannot assumed to be as broad as those from a more general background.

 

The Layman’s Guide to IT Architecture Roles

Most roles within information technology are fairly well understood and defined but this can’t always be said of architects.  This can be a problem for anyone considering a career progression into architecture – exactly what are the options and how do you get there?

Here’s my view on what the architecture roles are that you’ll typically see in today’s market, and how you might progress to them.

How to define architecture roles

There’s two ways we can define architecture roles…

The first concept I want to clarify is that of the domain.  An architectural domain is simply a conceptual area within the wider IT / architecture landscape, for example: infrastructure, applications, data, security and so on.  These domains are essentially areas within IT and architecture just as disciplines such as cardiology and neurology are areas within medical science.

A simple way of understanding architecture roles is to consider them against these domains, specifically in terms of breath and depth:

  • Breadth – how many domains the role covers.
  • Depth – at what level of detail does the role typically operate.

structure-of-architecture-roles-breath-and-depth

Please note this is not a definitive list of all architecture domains.

The second way we can classify architecture roles is by placing them on a marketecture-tarchitecture spectrum.   In the simplest possible sense:

  • Tarchitecture (technical architecture) – deals with the actual components a solution is made up of, how it will actually work and how that technology is managed.
  • Marketecture – (a portmanteau of the words marketing and architecture) typically deals with views of the solution that are more readily understood by laypeople, and tend to focus on non-technical aspects. There are 2 or 3 different definitions of marketecture but the exact differences are not critical for an introductory understanding to architecture roles; see the end of the article for more information.

It would be correct to assume that there’s often tension between these two perspectives, however, it would be wrong to blindly assume that all marketecture is inherently evil and adds no value.

Architecture roles and how to classify them

In my world view, there are three broad types of architecture work:

  1. Enterprise Architecture
  2. Domain Architecture
  3. Solution Architecture

I want to call out these three because they account for the majority of architecture work out in the market, even if the person doing the work has a job title that sounds different.  In addition to these there’s a few outliers that are organically linked to these but which aren’t your classic architect role, or which defy the classifications I’m using here.  Let’s ignore those for now.

structure-of-architecture-roles-3-broad-examplesNote, the basis of this diagram isn’t necessarily new and it might be something you’ve seen before.

What about the whitespace between enterprise and solution architecture?  Diagrammatically the whitespace exists to make the diagram easier to interpret, however, in the real world the exact point at which one ends and the other begins will vary from one organisation to another, partially based on what work needs to be done and the people available to do it.   In simple terms though, solution architects tend to focus on project specific work, enterprise architects do not.

We’re now at the point of fundamentally understanding the difference between architecture roles (please forgive the role descriptions which aim to give an idea of what the role is about in less than 30 words).

Role Description Relative Breadth and Depth Marketecture – Tarchitecture
Enterprise Architect Strategic, high level analysis and architecture across the entire organisation. Broad, high level 90/10
Application Architect Strategic, high level analysis and architecture within the given domain, plus supporting delivery / project work. Narrow, all levels 50/50
Business Architect Narrow, all levels 50/50
Data Architect Narrow, all levels 50/50
Infrastructure Architect Narrow, all levels 50/50
Integration Architect Narrow, all levels 50/50
Network Architect Narrow, all levels 50/50
Security Architect Narrow, all levels 50/50
Solution Architect Analysis, architecture and design for a specific project. Broad, low level 10/90

Please note that the roles listed above is not definitive, you’ll frequently come across variations to these.  How I suggest you understand those variations is to start by understanding the concepts described above, and then figure out where those variations sit in that context.

A further word on Solution Architecture

It’s important to remember that for solution architecture, although in definition the scope of the role is broad, the practical scope of the role in terms of a specific project is relatively constrained.  This is why the term solution architect has such broad usage, and why many people struggle to accurately define it.

Consider this hypothetical example:

structure-of-architecture-roles-solution-architect-example

For this hypothetical project, the “scope” of the domains that the solution architect is dealing with is heavily focused on the application domain, with a notable amount of security work and a bit of data and infrastructure thrown in.  The point is that whilst the level of “depth” they will be working at will usually be relatively consistent, the pieces of the “breadth” they focus on will vary greatly.

The exact mix of domains that the solution architect will cover on a given project will depend entirely on several factors, such as the what the project is trying to achieve and what other skills are available to support the project.  Consider the example above; if the organisation has dedicated infrastructure and data architects then the relative effort the solution architect is likely to spend on those domains is much less than if the organisation does not have infrastructure and data architects.

Appendix: The Mysteries of Marketecture

There are a number of definitions of what marketecture is, the three below being the most relevant; you might find that in a given your specific context what marketecture means is a hazy combination of these:

  1. The Hohmann / Fowler view: the business perspective of a systems architecture, including concepts such as licensing, the business model, technical details relevant to the customer (i.e. not necessarily ‘real’ ones). Brand elements, and so on.
  2. The Ian Gorton view: an informal depiction of the systems structure, interactions and relationships, possibly augmented by labels that espouse the philosophy behind the architecture.
  3. The Urban Dictionary view: a fairly cynical view in which the architecture is dreamed up by the marketing department and has little to do with reality.

Done properly, marketecture should fall into definitions 1 & 2, and serve as an excellent support to stakeholder discussions throughout the life-cycle of solution development.

Further reading on Marketecture:

Software Estimation: How To Do a Rough Order of Magnitude

Here’s the best software estimation technique I know; it’s not as good as doing proper Planning Poker and then measuring your actual velocity, but it’s a pragmatic approach if you are forced to come up with a time-based estimate for political reasons or to support sales activity.

I suspect other people use this process or one just like it – no idea what they call it, but I tend to refer to it as a “Rough Order of Magnitude” or ROM.

At first glance it looks pretty straight forward and semi-obvious, but, like many things in life the detail is where the important stuff is.  So lets start with the main steps then get into the detail:

  1. Design the system:
    • On a whiteboard / paper.
    • Decomposed down to a reasonable level of detail.
    • Make a note of all related tasks (e.g. environment set-up), plus any assumptions and constraints.
  2. Do two estimates:
    • For each and every part of the design: “best guess” & “worst case”.
    • Include all the related tasks.
  3. Write-up.

Design the System

The objective here is to come up with a design that should work, and then identify each and everything you need to do to build it.  Effectively you’re aiming to design down to the module/component/widget level.

For example, if you’re building a webpage that searches a database this implies that your design will include:

  • A database.
  • Tables in the database (do know what the schema is likely to be?).
  • The tables will have to be query-able (so will you write Stored Procedures?).
  • And so on.

Here’s some real-world examples of the kind of thing you’re after:

As you go through the process of coming up with the design you’ll be making assumptions, working within constraints and coming up with questions that influence the estimate – make sure you note these down.

Other tasks – things that aren’t part of the solution but will be part of the work/effort in delivering the solution; make sure you note these down as well.  For example:

  • Setting up development environments, source control, etc.
  • Setting up development servers, databases, access to them (permissions), and so on.

Estimation

Once you have the design you need to go through each module/component/widget and every task, and for each of them you want to come up with two estimates:

  • Best Guess – the shortest amount of time it could possibly take.
  • Worst case – the longest amount of time it could possibly take.

For example, let’s assume you needed to deploy part of the solution to Azure (or AWS) – but you have never done this before:

  • Your “best guess” might be half a day:
    • Because it’s only uploading  a package, how hard can it be.
  • Your “worst case” might be 3 days:
    •  Half a day just to login because the details you get given will be wrong / the account will be the wrong type / you won’t have the level of access people said you’d have, etc.
    • A day to do get hold of a test package that you can actually upload, plus all the research and reading you’ll need to do to figure out what it is you actually need to do, maybe even some time to do some quick prototyping.
    • Half a day to refactor your configuration options and redo your build so that it will now work based on what you just learnt.
    • A day to actually upload it and then figure out how to verify you’ve done it successfully.

As you might have figured out, the best guess estimates are where you can be an optimist, you can assume all your assumptions are correct, you’ve successfully mind-read the clients intent, there will be minimum defects, you’ll have no security / permissions issues connecting to the server the first time, and so on.

With the worst case estimates you do the opposite: feel free to take a hard line on stuff, assume your assumptions are wrong, that the data will be far more complex than you hoped, that the test data you get will be of really poor quality, and so on.

The key thing is to keep the estimated grounded in some rationale, that’s based on your experience and can be justified.

If you’re working on a whiteboard, just put your estimates straight onto the design (use a different colour).

Use any unit of time you like that makes sense (hours, days).

The significance of two estimates

This is one of the more subtle but powerful aspects to providing two estimates: the bigger the difference between the best & worst cases, the more pronounced the risk profile. This can apply to the overall ROM but it’s especially interesting at the task/component level. Consider:

  • You’d expect relatively larger items to have relatively bigger estimates – and a relatively larger best/worst range.  You might not think this means a greater level of risk, but remember that Planning Poker specifically uses a number scale that rapidly increases in size; the reason for this is that larger items are inherently harder to accurately estimate.  To me, this means they automatically attract a higher level of risk.
  • Ignoring the sheer relative size of an item, a bigger best/worst estimate probably suggests you’re less sure about the nature of the item, that it has more assumptions and unknowns.  All reasons to consider it to be a greater risk.

Once you’ve finished the initial estimation of all items and tasks, review those that have abnormally large best/worst estimates.  can you break them down into smaller pieces?  If not, discuss them and note down any risks and assumptions you identify, and include these in the write-up.

As a team or individual

I have taken this approach on my own, but usually it’s as part of a small team – e.g. if I’m the solution architect on the project and we get given a new major feature to estimate.  I’ll take a few of the key developers into a room to thrash it out.

As per Planning Poker, estimating as a group is always better, specifically:

  1. Estimates arrived at by consensus are usually more accurate.
  2. Others will spot stuff you missed, and a fresh pair of eyes is always good.
  3. It’s way more fun.

Going further, use the other tenets behind Planning Poker:

  • Avoid cognitive bias / anchoring – i.e. when discussing the system, especially when you get close to estimation.
  • Let everyone think of their estimate before people start revealing their own.  Because you’ll be estimating using actual hours or days you can’t really use a card-deck, so you’ll probably just have to rely on people being honest and not privately changing their estimates when they hear someone else’s.  Adjust your level of ceremony as you see fit.

Write-Up

At some point you’ll need to provide the estimates to someone.  What I tend to do is take photo’s of the whiteboard (to capture the design).  The assumptions, questions and so on I’ll usually jot down straight into OneNote so they are already digitized – that way I can just dump them into my write-up.  Usually the write-up will be semi-informal, possibly just an email.  You don’t have to waste time with unnecessary formality and ceremony – but the write-up should:

  • Be very clear.  Senior stakeholders / non-techs should at least be able to follow the narrative and understand the bottom line.
  • Come across as a professional piece of work, so that people won’t start questioning it’s validity based on how it is presented.

Remind people that the ROM is not a schedule, it has no sense of inter-dependencies or elapsed time, it is merely a sense of how big the work is and what the solution might look like.

Take particular care to explain and emphasize that you are providing a range not a quote. Overly zealous sales people and project managers will be tempted to take the smaller estimate and only provide this to the client.  Make sure they understand this is ill-advised. If you are hard pressed say: “the guy who wrote the article said that in his 16+ years involved in software development, every time someone took only the lower estimate things ended badly”.  If you’re from that British school of understatement, spoken with a touch of Jeeves-to-Wooster, you can say that the results will be “sub-optimal”.

You may also choose to throw all the items into a spreadsheet, with the two estimates, so that you can easily tally them up, include them in estimates back to the client, and so on.

Pros & Cons

The estimates are only as good as the experience and professional judgement of the people involved; the estimates are effectively based on nothing more than peoples prior experience, so ensure that those doing the ROM know what they are doing.  Involving juniors is good – it’s a great learning opportunity for them, but ensure they aren’t being left to fend for themselves.

As an estimation technique, it’s fairly fast and light-weight (but with a degree of rigor) so it’s useful in fluid situations.

Architectural Cheat Sheet (v3.0 – 2009)

I came up with this cheat sheet way back in 2009-ish.  At the time I was a real junior architect.

Looking at the sheet now there’s clearly areas where I have a grasp of the concept but I’m not using the correct terms, and in other areas I’d probably approach things a bit differently.

For this post I’m not going to correct everything as I think the old cheat sheet still offers an interesting point of view.  So if I was to redo this now, how would it be different?  Who knows – sounds like I just got a new to-do item.

 

Basic questions that apply to everything

Who – What – Where – When – How – Why

Time based aspects

  • Is this the first time (new) or a repeat (existing)?
  • How likely is reuse: how soon, how often, by whom?

Structure vs Behavior

(That’s it, simple as that.)

 

Performance Influence Matrix

Factors relevant to performance.

Users Transactions (Handled by a package) Data-Flow (between packages)
Frequency (peaks, etc)
Volumes (totals, etc)
  1. Throughput – Transactions per unit of time.
  2. Performance – Elapsed time per transaction.
  3. Latency – Wait time for a response.
  4. Capacity – Number of users / entities the system can support for a given configuration at a fixed level of performance.
  5. Scalability – Ability to increase capacity.
  6. Reliability – Length of time a system can operate without failure.
  7. Response Time – Performance as perceived by a human.

Security Matrix

Factors relevant to security

  1. Protection of data, both at rest and in-flight
  2. Protection of resources (misuse of services / functionality)
  3. Protection of systems (DOS, Out-of-band attacks, etc)
  4. Boundary defense vs in-depth (e.g. encryption)
  5. Authentication
  6. Authorization
  7. How will Authentication & Authorization be enforced, be managed?

Logical Layers (not including hardware)

  1. User Interface
  2. Application Layer (Service Layer or Controller Layer)
  3. Domain Layer (Business Layer, Business logic Layer or Model Layer)
  4. Infrastructure Layer (data access, logging, network access, security, email, file system, and so on)

Lifecycle

  1. Design, Prototyping
  2. Development / Refactoring
  3. Testing (suitability, integration, performance, …)
  4. Deployment / Use

Management Matrix: Who owns and controls what?

The point here is to take the concepts of Stewardship and Custodianship and apply it to the different parts of the stack.

Ownership Control
The process (that the system implements)
The hardware
Platform (OS)
The system(s) (software / services)
The data

Business / Project Management

  • What are the Critical Success Factors?
  • Is there a common terminology across all involved parties?

 

Information Architecture

  1. Organization / Structure
  2. Labelling
  3. Navigation, Browsing
  4. Searching

 

Information Lifecycle

  • Create, Read, Update, Delete

 

Transactions

  • Atomic, Consistent, Isolated, Durable

 

Architecture -> Capabilities -> Features

  • Execution qualities: such as security and usability, are observable at run time.
  • Evolution qualities: such as testability, maintainability, extensibility and scalability, are embodied in the static structure of the software system.

 

Some System Quality Attributes

  1. Accuracy: Indicates proximity to the true value (how close are you).
  2. Precision: The repeat-ability or reproduce-ability of the measurement (consistency within certain bounds).
  3. Modifiability: Requirements about the effort required to make changes in the software. Often, the measurement is personnel effort (person- months).
  4. Portability: The effort required to move the software to a different target platform. The measurement is most commonly person-months or % of modules that need changing.
  5. Robustness: the quality of being able to withstand stresses, pressures, or changes in procedure or circumstance.
  6. Performance
    1. See “Performance Influence Matrix”
    2. Expected transaction & response times (average, worst case)
      • response times
      • transaction rates
      • throughput
  7. Availability
    1. Service Level Agreements
    2. Percentage of time available and/or hours of availability
    3. Expected recovery time
  8. Compatibility
    1. Backwards compatibility.
    2. Dependencies – do they change between versions.
  9. Extensibility: New capabilities can be added to the software without major changes to the underlying architecture.
  10. Modularity: Well defined components, separation of concerns.
  11. Maintainability: the ease with which a software product can be modified in order to:
    1. Correct defects
    2. Meet new requirements
    3. Make future maintenance easier
    4. Cope with a changed environment

 

Operating constraints

  • System resources (storage, memory)
  • People (hours of business, location)
  • Software (dependencies, minimum requirements)

 

Deployment

  • Physical location
  • Political location (e.g. hosted internally or externally)
  • Ease of access (maintenance) vs. Security
  • Dependencies
  • Communication between locations/servers/etc (how, management matrix, etc)

 

Levels of Granularity

[Macro >] Systems / Components / Classes [< Micro]

 

Some possible Views & Perspectives

  1. Logical (typically coarse grained view)
  2. Functional (fine grained logical view)
  3. Deployment / Physical
  4. Business Process (and specific roles within that)
  5. Specific scenarios (both business and technical)
  6. Application (Class / Module / Package / Component / Service)
  7. Run-time (Concurrency / processes / threading)
  8. The User.
  9. Various stakeholders
  10. Data
  11. Security / Attack Surface
  12. Public / private, internal / external

 

Other things to consider

  1. Alignment with current and future technology stacks, industry trends
  2. User Interfaces
  3. Backend Interfaces / integration
  4. Context
  5. Responsibilities (both within the systems, and teams delivering them)
  6. Design Patterns
  7. Platform(s)
  8. Appropriate Granularity
  9. Supportability
  10. Maintainability (evolvement – extension – refactoring)
  11. Dependencies (on other parties, systems, services, standards)
  12. Interoperability adherence to standards, or: is achieved when the coherent, electronic exchange of information and services between systems takes place.
  13. Portability
  14. Resilience / Robustness: the quality of being able to withstand stresses, pressures, or changes in procedure or circumstance.
  15. Resource constraints (processor speed, memory, disk space, network bandwidth etc.)
  16. Scalability (horizontal, vertical / out, up)
  17. Security
  18. Usability by target user community

Availability In Real Terms

[Re-posting content I originally published in 2009! Some how it had gotten lost – it now returns]

I though it’d be worth defining ‘availability’ in real terms – terms that any non-technical person could understand.  After all when someone says %99.9 – exactly what do they mean?  As always – how you ask the question is just as important as the answer.

Availability in Real terms

Availability in Real terms - maintenance window

PDF: Availability In Real Terms