Wednesday, October 15, 2014

Architectural Drivers: Building Blocks for Decision Making

Architectural drivers are formally defined as the set of requirements that have significant influence over your architecture.  In other words, there are some requirements that will help you decide which structures to pick for your system design and others that are less consequential in the context of software architecture.  This implies that it is extremely important to get the architectural drivers right early in a project, as architecture structures will become more difficult to change as the developed software becomes more realized.

Thinking about early requirements as "drivers" can also help you to create traceability from stakeholder concerns to specific architectural decisions made.  Having this traceability is great because it helps to promote important qualities in your team, such as agility.  With traceability you can make changes on purpose and with confidence as you understand the genesis for structural decisions.

What are Architectural Drivers?

Architectural drivers have significant influence over the design of a system and are the determining factor over whether one design is “better” or “worse” than another that produces the same features. Architectural drivers are nearly always divided into four categories.  Some people might go with only three categories (talking generally about constraints), and others might include other things as drivers, but if this is your first time working with architectural drivers you should start with these four categories before tailoring.

Architectural drivers can be one of the following.
  1. Technical Constraints
  2. Business Constraints
  3. Quality Attributes
  4. High-Level Functional Requirements
Let's go into more detail for each of these categories.

Technical constraints are technical design decisions which absolutely must be satisfied in the architecture. These are generally fixed from the beginning of a project and may be expensive to change as the project progresses. Constraints, as the the name suggests, cannot be changed.

Business constraints are decisions imposed by business considerations that must be satisfied in the architecture.  Like technical constraints, business constraints are generally fixed from the beginning and have a significant influence on decision making for the design.  Likewise once in place these are considered unchangeable.  An example might be a specific delivery date, budget, or 

Quality attributes, sometimes called quality requirements, are specific criteria by which a system’s operations can be judged – that is, how well a system performs specific functions. Quality attributes greatly influence the design of the system.  In many cases, the same functionality can be achieved in a number of ways and so it is the quality attributes that ultimately determines when one design is better or worse than another.  Quality attributes receive a significant and thorough treatment in Software Architecture in Practice and you can read a sample chapter introducing quality attributes online.  Quality attributes are recorded as scenarios that describes a qualitative response within the context of specific system functionality.  For example, performance is a common quality attribute, but performance when the system is doing what?

High-level functional requirements provide an overview for what the system will do, the functions and features of the system. These might take shape in any number of formats from epics to stories to use cases to ye olde "shall" statements.  While quality attributes might determine specific structures you choose, the ultimate goal of the software you are building is to build achieve some bit of functionality.  From an architecture perspective, you won't go to exhaustive detail, and indeed it's best not to go into too much detail as diving deep too early can seriously delay the project.

What about Non-Functional Requirements?

If you've read any of the software engineering literature, you'll see the term "non-functional" requirements used fairly often.  The basic thinking was that there are these things that are functional requirements, and then there's things that are not functional requirements, non-functional requirements.  Setting aside the fact that calling requirements "non-functional" is completely dumb, this term comes up enough that it's important to understand it in the context of architectural drivers.

Most of the time people are referring to constraints and quality attributes when they talk about non-functional requirements.  Unfortunately, most of the time teams will lump all "non-functionals" into a single list. This is unfortunate because knowing specifically what kinds of drivers you are dealing with gives you a lot of decision making power.

Functional requirements are negotiable and must be shown to be correct.

Constraints cannot be changed once fixed.

Quality attributes imply trade-offs and often can't be directly tested until very late in the system's lifecycle. As a result you will need to find proxies, run experiments, and reason about the structures you've selected to determine whether or not you've promoted the right quality attributes.

Tuesday, May 20, 2014

Five Challenges for a Maturing Discipline

[At the opening for SATURN 2014 I presented five challenges for the software architecture community as a means of kick starting our brains for the conference, but also a serious reflection on the state of software architecture practice.  My hope is that these challenges are something we can work on together as a community and are my attempt at capturing something actionable that we can do to accelerate software architecture's maturation.  On the surface these five challenges are pretty simple. Of course if it truly were simple then it wouldn't be much of a challenge. Think about them. Give some of them a try. Let me know what you think.]

A little less than 20 years ago, Mary Shaw and David Garlan published a book reflecting on trends they noticed were emerging in software development.  The book's subtitle was extremely fitting: Perspectives on an Emerging Discipline. My reaction to the book, having read it for the first time for a software architecture class in 2008, was that it was grand in scope yet unassuming.  Having had the opportunity to meet and work with both David and Mary while a student at Carnegie Mellon, I found that the tone of this landmark book is more a reflection of who they are than anything else.  Essentially they proposed to the software engineering community, "Here are some interesting ideas and trends we've noticed and we think they are worth taking seriously, but these ideas need some further thought."

While Perspectives was certainly intended to be a unifying, landmark work, Mary and David had the wisdom to recognize that this was only the beginning, that this emerging discipline of software architecture must continue to mature, and that others must be responsible for the growth of the practice.

Sunday, March 23, 2014

I'm going to SATURN 2014 and you should too!

The SATURN 2014 conference is taking place this May 5-9 in Portland, OR. You should consider joining me at this essential software architecture conference. Register now online while tickets are available!

After graduating from Carnegie Mellon with a Master in Software Engineering degree, I needed a way to stay relevant on software engineering topics. As great as it would be, taking time off of work to earn a new degree every 5 to 10 years just doesn't work. It’s time consuming and stressful, not to mention cost-prohibitive. Rather than going back for more degrees, I decided that I would attend at least one professional conference every year. Ideally, I also try to present or write at least one paper every year too, but attending at least one conference is the most important goal.

This year my conference of choice is SATURN 2014. I decided to attend SATURN this year for a number of reasons.
  • SATURN is the largest conference dedicated exclusively to software architecture practitioners (not academics) in North America. I will only attend conferences where I can learn something that I can actually use in my job. My expectation is for a high density of practical knowledge.
  • SATURN is one of the few conferences in the world dedicated to software design principles and practices. There are lots of conferences out there on methods. Tons of conferences on programming and specific technologies. SATURN is one of the few conferences that examines these topics from the perspective of architecture and software design. This perspective if desperately needed sorely lacking in software professionals today.
  • SATURN is an established conference. The conference is co-hosted by the Software Engineering Institute and IEEE Software, and this year marks the 10th consecutive conference held. The SEI and IEEE are responsible for having established and promoted nearly every standard practice in software architecture that has ever existed. Their participation in this conference is a strong indicator of the kinds of topics that will be covered.
  • SATURN is attended by the folks who define software architecture. Here are just some of the software architecture thought leaders who are speaking at SATURN -- Philippe Kruchten, Rick Kazman, Len Bass, Robert Nord , Felix Bachman, George Fairbanks, Ipek Ozkaya, Jeromy Carriere, Rebecca Wirfs-Brock, Ted Neward, Linda Northrop, and more…

    If you measure a conference by the number of speakers who have a Wikipedia page, this conference has at least 5. Bonus points if you can find them at the conference.
  • SATURN has a good mix of presentations, workshops, and longer tutorials. The tutorials and classes are top-notch. I personally am looking for advanced tutorials and workshops to attend and SATURN has these. There’s also a couple with introductory information for software engineers just getting started in the world of software architecture.
  • SATURN is hosting a co-located Open Space facilitated by Diana Larsen. I’m an explorer. When choosing a conference I look for opportunities to explore beyond the established program. I love a good Open Space conference and I am very much looking forward to having an Open Space filled with software architects. I am even more excited that Diana Larsen will be the facilitator. She has done an amazing job facilitating at the XP conference in Europe every time I have been.
  • SATURN keynotes this year look amazing. It’s unusual for me to attend a conference based on keynote speakers. Most of the time I’m not that excited about the big speakers and I’m really looking at the overall topics in the conference. That said, the SATURN 2014 keynote lineup looks really solid.
  • SATURN is held in Portland, OR this May 5-9. Timing and location also play a significant role in my deciding what conference to attend. I have always wanted to visit the Pacific Northwest and Portland in particular. I’ve heard so many amazing things about Portland that I really need to see it for myself. May is also a great time for a conference, at least for me. I must admit that if I could afford to go to Europe this year, I am extremely tempted by XP2014 in Italy.
I should mention that I am serving as the technical chair for this year’s SATURN conference. You should view my serving as the technical chair for SATURN as the greatest possible endorsement I can give a conference. Given the massive time commitment required to plan and organize a conference, I can’t afford to spend time on something that I do not feel is massively important to software architecture, and something that is not great. SATURN is important to our profession. SATURN is a great conference. I very much hope to see you there this May.

Other Conferences of Note:

  • Software Architect London -- I would call this SATURN's sister conference for Europe.  I have not attended, but it is pretty close in terms of quality of program to SATURN and a good choice if you are from Europe.
  • XP 2014 -- outside of SATURN XP is my favorite conference after having attended twice.  The biggest problem for me is that it is in Europe.  Like most Agile conferences it is usually light on software architecture (albeit the strongest architecture presence of the Agile conferences I've attended), but the locations, excellent planning, and dedicated research track more than make up for this.
  • Agile 2014 -- Agile has been expanding to include Agile coaches and UX topics, which has shifted the focus away from core software development.  That said, if you pick the right tracks this is a great conference.

Thursday, January 2, 2014

Formal Models: I Hate You, I Love You

My view on formal methods is somewhat... nuanced.  In spite of this I'll go ahead and start with a ridiculously strong and outrageous assertion that I can use as a toe hold for further discussion:  Formal specifications do not have a place in agile software development.  Don't get me wrong. As a software engineer I like the idea of formal specifications very much.  They are precise.  They are unambiguous.  They are... engineering-y.  But as a post-modernist software engineer I also think formal specifications are kind of a dumb idea. They are tedious. They are cryptic. They are... anti-human.

For decades software engineers seem to have put formal specifications on a pedestal as if they were the Michelangelo's David of requirements.   But while Michelangelo's sculpture of David manages to perfectly capture the essence of humanity in marble, even the most elegant formal specifications fail to fully capture the perfect essence of desired functional behavior of a software system.  The fatal flaw of formal specification comes from removing the human element and assuming that cold mathematical precision is an adequate model for communicating and comprehending human desires.  (Yes, I am creating a straw man, but please allow me to beat him up just a little more before providing a counterpoint.)

A common example formalists use to demonstrate the strengths of formal specification (and weaknesses of plain old English prose) comes from the alleged ambiguity and confusion created by various warning signs posted by escalators throughout the UK.  "Dogs must be carried," the signs read.  "What if I don't have a dog?  Can I still use this escalator?" the formalists rhetorically ask, I always imagine with a smug grin.

Dogs Must Be Carried!
The more important question:
What happened to that dog's butt?

Monday, June 24, 2013

Rapid Software Architecture Exploration

At XP2013 this June in Vienna, Austria I ran a brand new workshop titled "Rapid Software Architecture Exploration."  In the workshop I presented a framework for thinking about software architecture design based on my essay, Exploring the Design Space, and gave participants a chance to put the theory to practice using four different exploration activities. Slides and handouts from this session are available online.

Huge thanks to everyone who came to the workshop.  Everyone did an amazing job and really ran with the activities we did.  I think the end results were very good -- surprisingly an almost fully architected system in only 45 minutes (plus some of the prep work that I did ahead of time).  I have no doubt, now even more so, that with a good facilitator and the right people in the room you can accomplish in hours or a few days what traditionally could take weeks.

The session was great because you guys made it great.  Thank you!  If you use these workshops with your teams or customers, let me know how it goes, I'd love to hear from you!

Monday, May 6, 2013

Overcoming Team Dysfunctions: From Storming to Awesome

Forming, storming, norming, performing, mourning -- the stages lof team formation.  I’ve experienced this natural progression a few times, transitioning from a group of strangers to a well-oiled machine – to friends.

One team I worked on figured out a way to collect data and measure our journey from new to awesome.  We didn’t know about this standard team lifecycle when we started, but that didn’t mean we could avoid it.  In fact, as you’ll see in this essay, embracing the steps of team formation helped us move through the phases and become a highly efficient team that much faster.

Monday, April 15, 2013

Boxing the Infinite Design Space

When I work on a puzzle I start by making piles of pieces that seem like they go together.  When I find a distinguishing feature on a piece (like an eye or a unique color for example) it helps me fix a position and I can start connecting pieces together.  If I can figure out where a pile or set of connected pieces should be relative to one another I try to place them approximately in the right spot on the table relative to the other piles I've made.

The most important pieces are the corners.  The only problem is that there are only 4 corner pieces (out of thousands) and in some puzzles it's impossible to determine just by looking at the piece, in which corner that piece belongs.  Edges are helpful too but without some kind of context it's difficult to know if an edge belongs on the right or the left, the top or the bottom.

pile of puzzle pieces

With each puzzle piece slowly being discovered and placed, I am slowly exploring the available options for putting the puzzle together.  By identifying essential landmarks, I'm defining boundaries that let me explore within a specific context without venturing too far into the weeds.

Jigsaw puzzles are technically finite (there's only 1000 pieces in a box), but I wonder if there is still something to learn from puzzle building strategy when approaching a software design problem with theoretically infinite possibilities.  How can you quickly explore the design space so that you focus your effort on the design decisions that matter most?  Is it possible to efficiently draw a boundary around the seemingly limitless design options of a software system?

Wednesday, March 13, 2013

Play Telephone with your Architecture Description

The game starts with a simple phrase.

I heard that Sally ate nine cooked crabs and a plate of shoestring potatoes but later decided that eating crabs was wrong.

You tell the next person, quietly so no one else can hear.

I heard that Sally ate nine cooked crabs with a plate of shoestringed potatoes and decided eating crabs is wrong.

And that person tells someone else.

Sally ate nine cooked crabs with shoestring potatoes and she thinks eating crabs is wrong.

Who tells someone else.

Sally ate nine cooked crabs with sho-shu potatoes and she tin cans wrong.

And in theory, the last person hears the same message as the first person.

Ally ate nine crooked crabs with shoo-shoo potatoes and something about tin cans singing songs.

But it almost never works out that way in practice.


Tuesday, February 26, 2013

High Ceremony Software Architecture Kills Collaboration

I was a panelist on the "Architecture and Collaboration" panel at the SATURN 2012 conference in St. Petersburg, Florida this past May. For the panel I was asked to provide a single slide stating my position. This was my first time sitting on a panel and the first time I was ever required to have a clear "position" on a subject. It took a long time and a lot of thinking before I finally was able to A) understand what my own position was, B) have a position that would differentiate me from other panelists (we all by and large have the same opinions toward architecture and collaboration), and C) articulate it in such a way that I could fit it on one slide.

My position was simple, clocking in at 4 words: "High ceremony suffocates collaboration."

Saturday, February 16, 2013

Reflection on Past Essays and the Path Forward

After a few years of paid hosting, I’m moving my blog to Google Blogger. When I first bought hosting I imagined all of the interesting, amazing web applications I could build. Sure, I built a few things here and there, but over time the web evolved and the free tools available have improved greatly.

As a part of the migration I moved all posts and comments, doing my best to keep everything as true to the original post as possible. In the case of comments, I migrated the exact text you left along with your name and web address. Unfortunately this means your gravatar ID verification will be lost and nothing will be connected to Google or Google+ IDs. This really makes it obvious how difficult the whole idea of “identity” can be on the web.  If you see a problem, let me know and I'll fix it.

You might also some notice some hiccups in the RSS feed (including a Twitter blast), and for that I apologize. Though, maybe thanks to these hiccups you will take a few moments to read some past posts. I’ve had a good time re-reading old essays and seeing how much I’ve changed over the past few years. And how much I’ve stayed the same.

With this in mind, and with it being a new year, I thought this would be an excellent time to reflect on the trends and ideas I’ve written about over the past three years. All told that’s about 40 essays worth of content.