Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
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.
I would say it depends on what level the document describes:
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.
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.
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.
