Skip to main content

Software architecture; the lay of the land -

Purpose

Given the plethora of genres of architect that are sought on [insert your favourite job search tool].com, I thought it would be worth writing a post on this subject, to help myself and anyone else who may be inclined to ponder software architecture, better understand the lay-of-the-land within and outside of their own organisation.
This post is actually a loose assembly of my own thoughts and previous posts that I have made on the matter of programming and architecture; I have copied/pasted, and stitched together to form a somewhat coherent document.

Definition

"An architect is a person trained and licensed to plan, design, and oversee the construction of buildings. [...]"
Here's a picture of a Saab – according to Top Gear, all construction type architects own one of these:


[A Saab]

But this post is about software architecture...

So how does architecture relate to programming?

To be clear, architecture is by no means a final or inevitable destination in the career of a programmer. It is more a way of thinking than a "job", and in-fact, a good architect may not necessarily be (or have been) a good programmer.
Architects like to think about the big picture – business implications, what the customer thinks, how a design will fit with company/product strategy, project scope, etc – hence their work is much "fuzzier" than the programmer's. By contrast, a programmer may love the intricacy and precision of their work; designing a complex system at the "nuts and bolts" level and seeing it come to life.
Fred Brooks puts it like this in his influential book The Mythical Man Month:
"[programming is] the fascination of fashioning complex puzzle-like objects of interlocking moving parts and watching them work in subtle cycles, playing out the consequences of principles built in from the beginning. The programmed computer has all the fascination of the pinball machine or the jukebox mechanism, carried to the ultimate."
Neither programmer nor architect is "better" than the other, but they are different and can be expected to have different interests.
As the profession and industry of software development matures, we have an ever-increasing volume of historical accomplishments and/or issues to look back on and pat ourselves on the back about, or alternatively facepalm – depending on how you look at it!


[Faceplam]

We now understand that it's not how much code is written that is important; what's really important is the quality of the code and whether the code implements a product that meets the customer's requirements. Movements like Agile and Lean (as it applies to software development) reflect this thinking – but that's another story...
Successful software architecture is to a large extent guided by looking to and applying learning from our own history; certainly architecture is more about this, than it is about trying to find new and exciting ways to apply the latest/greatest technologies known to humankind.
Depending on the type of organisation, architecture may be more-or-less important. An organisation that aspires to be a product company for example, may put more emphasis on architecture than a services or utility type company (power, telecommunications, etc). 
To elaborate; imagine a suite of products with implementations geographically/physically distributed across many countries, sites and customers. Design decisions in this situation made around software development can have a far reaching impact. By comparison, "internal" software systems (the services or utility company, for example) maintained by an internal team of programmers, can be manipulated and modified with relative ease; the implication being, priority of design may be overridden by convenience in this situation.

Types of architect/ure

So what are the various "flavours" of architecture that we may come across, within and outside of the organisations we work with?

Solution architecture

The goal of solution architecture is to produce a customised solution for a specific customer. The solution may end up being part of a product, but initially at least, is tailored to a specific customer's (or group of customer's) requirements to solve a specific problem.
Wikipedia sum up solution architecture quite nicely: http://en.wikipedia.org/wiki/Solution_architecture

Product architecture

This is a relatively old discipline that is applicable to areas outside of software development.
One definition is as follows: "The arrangement of functional elements into physical chunks which become the building blocks for the product or family of products."
Here's a slideshow that Berkley provides online, relating to PA: http://best.berkeley.edu/~aagogino/Slides/11_SPD_platforms.pdf
Basically the role of the product architect is to think about the products in a company's portfolio and how they can be developed, improved and streamlined in order to make them more marketable, maintainable and effective.

Enterprise architecture (edited 20140714)

Enterprise architecture (EA) departs from other types of architecture in terms of definition and function - it is more of an introspective business discipline that leans on technology (business process design/mapping, automation/improvement, etc) than the other way around.
With the world becoming more-and-more interconnected and automated, and with new ideas being able to be brought to market faster and faster, there is a growing interest in EA as a means to improve internal business process. 
Several EA "frameworks" have sprung up in recent years - here's Microsoft's comparison:
Effective internal business process can be seen as a way to gain competitive advantage, since internal process is harder to imitate (by competitors) and easier to control (by the enterprise) than external factors. Examples of external business factors would be product marketing and development, price-based competition with other companies, etc.

EA's goal is to change and improve internal business process, which is in-turn expected to result in improved ability to successfully negotiate and manage external factors, thus enhancing and enterprise's overall competitive advantage.

Agile architecture

Another more recent addition to the list of types of architecture, and a growing movement, is the concept of "Agile" architecture:
The Agile architecture concept essentially says that architecture is a collective and emergent thing.
The role of the architect in an Agile team is one of bringing ideas together, making sure people feel comfortable sharing their ideas and then assembling the team's thinking to form a coherent "way forward" from a combination of the group's collective thinking and the architect's personal judgement. Sounds a bit "new agey"...but Agile is a bit like that.
Indeed, the role of "Agile Architect" in a team may not necessarily be held by an individual, but exist in the collective thoughts and opinions of the team, as a means to achieve a specific goal.

Concluding thoughts

Although we use titles to distinguish functions, within a single company/industry many of the above "flavours" of architecture may bleed into each other.
People's titles reflect their various backgrounds and interests, and what they are expected to be able to contribute in a team context. Despite this, we may find that the acting architect on a project/team may not hold the title of architect, but rather, be a senior developer, team leader (perhaps even a PM!), etc – essentially, someone who knows and/or has more experience than most about a particular problem/domain.
In Patterns of Enterprise Application Architecture (recommended reading for anyone who is in software development/design-esque line-of-work) Martin Fowler describes software architecture as being:
"The highest-level breakdown of a system into its parts; the decisions that are hard to change; there are multiple architectures in a system; what is architecturally significant can change over a system's lifetime; and, in the end, architecture boils down to whatever the important stuff is."
This seems to fit – basically, in order to deal with architectural decisions and problems, it helps to have the desire to be involved with this type of fuzzy stuff, and also the experience to be able to make informed/effective decisions in the face of fuzzyness – or at least, to get yourself (and the system) out of the schtuk if you make the wrong decision.


[Stakes is high: the "Ford Edsel" - http://en.wikipedia.org/wiki/Edsel]


Comments

Popular posts from this blog

HOW-TO: Apply a “baseless merge” in Team Foundation Server 2010 (and 2012)

Another purely technical post on TFS...
The scenario We wish to migrate code between branches that do not have a branch/merge relationship, in order to expedite urgent changes being made by a project team, without disrupting on-going BAU development work. Sample branch hierachy/strategy Imagine the following branching strategy in TFS (visible by connecting to TFS via Visual Studio 2010 or 2012):

Essentially you have a "DEV" branch, which has a "QA" branch, which in turn has a "PROD" branch. DEV is the branch that you would be using for BAU development. As a piece of development matures, you move it into QA, where it is tested by your internal QA team. There may be further changes made in DEV that are moved into the QA branch as the QA team pick up issues. Once the QA team are happy with a packaged of changes, they will move them into PROD, which is essentially the hand-over to the customer. The PROD branch represents the software that the customer has.

Mo…

HOW-TO: Add/edit a field in Team Foundation Server 2012 using Visual Studio 2012

It's been a while since I made a purely technical post...

So, today I wanted to make a change to a Microsoft Team Foundation Server 2012 (TFS2012) instance that I am working with to reflect "Actual" time spent on a task - mainly for reporting purposes, and because I have found in the past that making this minor process adjustment yields a relatively useful metric over the long-term.

I am using the Microsoft Scrum 2.1 Process Template (http://msdn.microsoft.com/en-us/library/vstudio/ff731587.aspx) for a project that I am working with. So that I don't forget how to do this (again!) I will blog-post the procedure I've used to add this field to the template as a screen-shot-based tutorial, as follows...
Before Assuming you are familiar with the Scrum Process Template (2.1-ish) - open a task and take a look at the "Details" section, as follows:


 This is where I want my "Actual" field to show up.
Get the Power Tools Download and install the latest v…

Eclipse/Android error: "Multiple dex files define [...]"

Wow, I am really going nuts blogging this-evening - 2nd post in less than an hour. 


Anyway this is a particularly nasty error that I keep running into with Eclipse/Android when starting the emulator after I have not run it for a little while. Since I run the risk of permanently forgetting the solution to the problem every time I walk away from my Android project (and thus having to spend a painful hour-or-so digging up the procedure again), I will blog it here, for my benefit, and for the benefit of anyone who may also suffer the same problem.


The gist is that when you start the emulator in debug mode (that is, you hit the button in the following image), you get the following error message come out on the console and a nasty popup telling you nothing more than there is an error with your program and you need to fix it:








[2012-04-06 23:20:57 - Dex Loader] Unable to execute dex: Multiple dex files define Lcom/google/gson/ExclusionStrategy;
[2012-04-06 23:20:57 - SimpleList] Conversion to Dal…