Random Acts of Architecture

Wisdom for the IT professional, focusing on chaos that is IT systems and architecture.

Tag Archives: Non-functional requirement

An Architect’s Place in Agile

3 Comments Posted by on August 19, 2012

Scrum, the most common implementation of the Agile development methodology, has many well-defined roles. Those that contribute directly to the sprint (a unit of work usually lasting 2-4 weeks) are called “pigs”. Those that consult or assist only are “chickens”, the “scrum master” coordinates the sprint and the “product owner” prioritizes work and ensures the customer needs are met.

So where does the software architect fit in? The architect is not a pig if he or she does not write production code. Is he or she a chicken? The architect needs to be driving his or her features in the sprint and be more involved than a chicken. The architect is not responsible for team organization and a customer representative is usually the product owner.

Going back to basics, why is a software architect needed? Architects are rarely needed in projects with small, co-located teams full of senior developers working on well-defined requirements or well-understood problems. They can usually design and cooperate well enough to produce the desired results. However, large, distributed teams full of junior developers working on vague requirements or complex problems need coordination and direction. This is where architects are most useful.

One way of looking at it is Scrum is a software development methodology, not a productization methodology. Software development is one part of producing a product but there are many other parts, particularly for commercially sold software, such as business case design, marketing, licensing, documentation and localization. The architect could deliver non-functional requirements and high-level designs outside sprints like the other non-development tasks.

However, the architect need not deliver a monolithic document for the high-level design. In keeping with the Agile manifesto, as well as the Lean principle of making decisions as late as possible, the architect only needs to produce enough of the design to unblock the next sprint. The architect will still need a high-level design and identify non-functional requirements initially but Agile recognizes that design is as much a process as a product. Designs for subsequent sprints can be fleshed out in parallel with the development team, minimizing design rework as the team learns more about the problem and finds better solutions.

Could a software architect use Scrum to create the high-level design, either separate to or in parallel with the development teams? This can work if the architect has easy access to the resources he or she needs, such as customers to help understand the business problems, architects from other teams to discuss integration and development managers to check resource estimates. This cannot be guaranteed, particularly with larger, distributed groups – the cases where architects are most useful. However, it will occur in practice if the architect is providing designs for the start of each sprint.

Indeed, if the product owner is remote or often unavailable, an architect fits best into Scrum as a stand-in product owner. This breaks the Scrum rules of only having one product owner. However, different time zones, large projects and multiple commitments mean a single person cannot scale, as a former colleague of mine explained.

Development management may baulk at the perceived loss of control by making an architect a product owner. However, the word “owner” in “product owner” does not mean control of the product, merely creating, prioritizing and clarifying tasks, which architects often do anyway. Architects may not be customers but are judged whether the product meets the requirements or creates business value, just like product owners. They also know the product strategy and have spent time with the customer understanding the problem so are well-suited for this role, using their judgment to determine whether to escalate each question to the product owner.

Moreover, I think the question is not “Where does the architect fit into Agile?”, it’s “How can architects leverage Agile to better perform their role?”. For example, the architect can gain more visibility into the development team’s progress and status (through the backlog and burn down charts). The architect can present the design and gain consensus at the planning meeting that starts a sprint and (hopefully) see it working in the hand-over meeting at the end of a sprint.

Most importantly, architects must be in control of their performance rather than victims of process. A lot of smart people have worked very hard on Agile and Scrum and developers new to Scrum are advised to follow it as written, at least initially, because the reasons behind its nuances are often unclear. However, no development methodology can handle every case, and software architects are one of those things that can fall into the gaps.

Software Architecture , , , , , , , , , , , ,

What is Technical Vision?

Leave a comment Posted by on December 16, 2011

Few things are so error prone and political as the architects’  “technical vision”. Technical vision identifies longer term technical goals (such as add iPad support or upgrade to the new database version) and describes how to reach them, perhaps over multiple releases. Clearly, this is only useful for larger, ongoing or technically complex projects.

Many architects aim for isolated technical improvements in their first technical vision. Unshackled from the constraints of time and resources, these are often ambitious, large-scale changes intended to make anticipated subsequent changes easier by adopting new technologies, creating reusable components and standardizing formats and protocols.

The first issue with this approach is that little is tied back to customer or business requirements. Otherwise, the architect risks an “ivory tower” situation, recommending or enforcing designs often blamed for inflated resource requirements and missed deadlines.

The best way to avoid this and gain credibility is to interview stakeholders, identify changes they want made and incorporate them into the vision. Non-business stakeholders like testers, localizers and documentation writers often want product improvements, too. Perceptive architects prioritize stakeholder requests that echo their own thoughts and, once the architect has demonstrated delivering these in products, architects will gain the credibility and latitude to add some of their own ideas.

The second issue is with component reuse and standardization. While the architect’s high level view is good for identifying opportunities for these and prioritizing them, links back to business requirements are difficult to articulate, particularly to non-technical stakeholders. Developers hold code written by others to a higher standard than their own (particularly documentation, quality, scalability and security), will use such components in ways never originally envisaged or intended and backwards compatibility requirements can limit improvements. However, the biggest danger with writing reusable components and standardization is the tendency to focus on them and not the problems they solve.

Writing reusable components and standardization are organizational decisions as much as architectural ones. Bugs or enhancement requests need tracking, prioritizing, fixing in a timely manner and distribution. Good approaches for reusable components include starting with small, non-critical components or creating internal “open source” projects where anyone can contribute, subject to review. Avoid forking components if possible.

Standardization requires a middle ground between forgoing features (“lowest common denominator” approach) and spending additional effort (the “kitchen ink” approach) and organizations must resist doing too much of the latter. It is best to start with often used interfaces and include security, scalability, performance, error behaviour and similar non-functional requirements.

Lastly, new technologies are often attractive, exciting and claim to solve problems more effectively, reducing development time and cost. However, adopting new technology requires an understanding of the whole system and not just isolated problems, lest it cause more problems than it solves. Once again, there is an organizational cost with retraining developers, purchasing new tools and integrating it with old technologies. New technologies are best trialled first with a proof of concept.

Good technical visions are known to and have the backing of both stakeholders and developers, which is easier if creating it involved them. Technical visions need not be detailed or specific, at least not initially and good technical visions are accessible, unambiguous and concise. If others cannot read them or understand them, it cannot be implemented or implementations will digress from the intention. As mentioned before in this blog, it is the architects’ responsibility to communicate the vision effectively.

Technical visions can change over time, too. This reflects changing business requirements, technology landscape and development techniques. It also reflects expressing the intention more effectively. Constructive criticism and discussion is vital, both to improve it and, as also mentioned before in this blog, incorporating others’ feedback gives them ownership and ensures it is current.

Software Architecture , , , ,

%d bloggers like this: