Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

When writing a software architecture document, should we present the technology used and how it connects to the system qualities we want achieve? For example, we chose .NET because arg1, arg2 ..

My feeling is NO, architecture should be stable in change; but the concrete realization of some modules can change in respect to the technology used.

share|improve this question

migrated from stackoverflow.com Apr 15 '11 at 7:43

This question came from our site for professional and enthusiast programmers.

add comment

4 Answers 4

I would say it depends on what level the document describes:

  • Enterprise architecture - no, specific technologies should probably not go in here, since this document should focus more on business processes, and high level components supporting them.
  • Solution architecture - yes, since the document describes a specific system.
share|improve this answer
add comment

If you're not listing technologies, then you're just listing concepts.

Concepts -- without a concrete application, and specific technologies -- aren't really very interesting.

Anyone can list a bunch of concepts and claim they all work together in some magical way.

architecture should be stable in change

Can't see what the point is. If you're just going to list concepts, they never change. But, it doesn't tell anyone what to buy, what contracts to sign, or what programming to do.

some modules can change in respect to the technology used

If so, where will you document the technology choices? That's what the architecture document is for.

It tells everyone what to use.

share|improve this answer
add comment

An architecture should present the technology used, but only for the public API and any shared resources.

If I'm trying to figure out how the inventory system is going to talk to the work order system then I need to know what my options are.

I don't really care if the system is developed with C# or Java, unless it affects licensing or hiring; I do care if it's using SOAP, REST, or some kind of EDI. I also care which version, and which protocols are in use. These need to go in an architecture document, otherwise it tells me nothing about the actual architecture.

I also care about the database - that's a shared resource. If I'm leaning toward ETL as a solution then it makes a pretty huge difference whether or not the source is Oracle or SQL Server.

Oh, and I need to know about dependencies. For example, if you've decided to use NServiceBus for your ESB, I need to know that because it requires widespread deployment of MSMQ, and as an architect I'm supposed to be able to say something about how reliable and/or scalable that is. Likewise, if you've decided to use WCF with Mutual Certificate authentication then we'd better be prepared to deploy a PKI.

On the other hand, I really couldn't care less whether you've chosen Spring or Castle for your dependency injection, or whether you're using Linq to SQL or Entity Framework in your .NET app. Please don't bore your readers with an insufferable account of the merits of log4net vs. NLog.

There's no simple "yes" or "no" answer - it's the same as asking how much technical detail you should get into during a meeting with your clients. The answer is "only as much as necessary". You're the architect; you're supposed to understand enough about the architecture to be able to determine whether or not some implementation detail has a broader impact on the entire system or enterprise.

share|improve this answer
add comment

Whatever view you document you'll want to show how desired qualities are promoted by your choices. If you don't feel that specific details help you describe that view then don't include them.

What you document will depend greatly on the view and the context in which technology decisions are made. Some technology decisions, such as frameworks, platform, or language are a big deal - they will have a significant impact on the system's architecture. Consider the audience and how you plan to use the architecture description.

In my experience it's useful to know what the technology decisions are and where they came from. For example, was the technology a constraint from the customer or a team decision? Beyond this I've found it's sufficient to briefly mention what a piece of technology provides, especially if it's something out of the ordinary for your team or if it is critical to achieving a specific quality.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.