Some methodologies of software architecture, including EWITA, attempt to describe architectural processes in a manner that is quite separate from the development of software. Is that valid?
To whit, the first step in the EWITA process is described as “architectural requirements.” Yet, there doesn’t seem to be any definition, on that site, about what criteria we’d use to decide if a requirement is architectural or not. So if my job is to collect architectural requirements (hmmm…), then I have to ask, “what is an architectural requirement, and how is it different from some other kind of requirement?”
Consider this analogy
A few years ago, when I was considering making an addition to my home, we called an independent architect to come over and discuss details. We talked about the functionality of the rooms, and where they would be attached to the house, and what changes we’d need to make to the rest of the house. All of these requirements were shared with the architect, and he was planning to consider them all when creating a solution. So are requirements architectural if the client tells them to the architect? I don’t think that is a useful definition. Are some requirements more inherently architectural than others? Good question. Some requirements came in the form of building codes. Were those architectural? Surely, they affect the architecture of the building, but so do requirements about function, size, and even the ease by which we would decorate a room.
A few years ago, when I was considering making an addition to my home, we called an independent architect to come over and discuss details. We talked about the functionality of the rooms, and where they would be attached to the house, and what changes we’d need to make to the rest of the house. All of these requirements were shared with the architect, and he was planning to consider them all when creating a solution.
So are requirements architectural if the client tells them to the architect? I don’t think that is a useful definition.
Are some requirements more inherently architectural than others? Good question.
Some requirements came in the form of building codes. Were those architectural? Surely, they affect the architecture of the building, but so do requirements about function, size, and even the ease by which we would decorate a room.
In software, the same problem occurs. Business customers describe their use cases. Sometimes we talk about using data from other systems. Other times, we talk about speed and performance. Mostly we talk about functionality. What the application will do, and how it will make their lives better.
I don’t differentiate requirements as “architectural” vs. something else. It is not a distinction that I find useful. My question, fair reader, is to you: do you have a practice of attributing your software requirements with a note that says “this one is architectural?” If so, what logic do you use to flip that attribute to “true?”
I’m just not seeing it.
For most of the last decade, we’ve seen a steady growth in the use of a simple “recommended practice” in the world of software architecture. Well known by it’s designation, IEEE-1471 is officially titled “Recommended Practice for Architectural Description of Software-Intensive Systems.”
The standard defines words, mostly. It answers the question: “What is Software Architecture” and does so in a simple and elegant manner using the concepts of model, view, and viewpoint. It is also written in somewhat vague language, with the meaning of some terms being assumed and others inconsistently applied. Creating a conceptual model from this document was no simpler than creating a model from a typical business document, even though it should have been.
Regardless of the relatively minor deficiencies of IEEE-1471, we find it a useful way to describe software architecture and our team in Microsoft IT has fully embraced the language and concepts of this simple and elegant approach. In addition to embracing 1471, we extended 1471 by linking in key concepts from the UML, as well as other notions like “common viewpoint types,” “architectural description methods,” and modeling languages.
A number of months ago, I created a small poster (designed to be printed in Tabloid size or larger on a color printer) that illustrates the value of this simple language. Embedded in that poster is a conceptual model that illustrates what these terms mean in relation to one another. I’m sharing the poster here, for others to benefit from.
My goal is to provide a simple way for all architects to illustrate, share, learn from, and talk about the language of software architecture. I hope that this poster finds its way into classrooms and team training sessions. Feel free to use the poster as a way to communicate and share. I did not author these concepts. I’m simply trying to explain them.
Note: the diagram uses some of the notational conventions of UML, but not many. If you understand the concepts of association, composition, and aggregation in the basic class model, you can read this diagram. The verbs on the lines between concepts are written so that a reader can read the association by following the arrow.
If you’d like the IEEE-1471 Extended diagram, without the rest of the poster, simply click the image below.
About a month back, I asked if it was time to create an MBA in Business Architecture. I’m going to follow up with a suggestion for a curriculum for such an odd degree.
The degree is provocative on its face. After all, an MBA is first and foremost, a business degree. Yet most Enterprise Business Architects are employees of IT departments. How do we mix the two?
I honestly believe that the core business skills focused on in the MBA are necessary but not sufficient to be a good EA. I believe that core technology skills are necessary but not sufficient either. You need a mix of both.
A good EA needs to be able to operate in both spheres: business and technology. They need to have excellent skills in both. That is why I wonder if the program at RMIT in Australia is sufficiently business oriented. On the other hand, the McCombs school of business in Texas has an undergraduate degree that mixes business and engineering. That seems interesting. There is also a university in Switzerland that has a degree in Business Engineering, but I couldn’t get many details.
The following curriculum suggestion was derived from two primary sources. The first is the Austin Texas MBA program mentioned above. The second is the listed curriculum of the Harvard Business School. In a few cases, I copied the course descriptions verbatim from one of these two sites. In most cases, I modified the course descriptions to represent the “flavor” that I would wish to see for a Business Architecture MBA.
This course introduces tools for studying the economic environment of business to help managers understand the implications for their companies. Students will learn the impact of: National income and balance of payment accounting, Exchange rate theory, Political regimes, and regional global integration issues. These integration issues include: International trade, Foreign direct investment, Portfolio capital, and Global environmental issues.
The objective of this course is to help students develop the skills for formulating strategy. Strategy development provides an understanding of a firm's operating environment, competitive advantage, customer value proposition, activity configuration, and balancing the risks and opportunities available to an enterprise with the business strategy in mind. The first module focuses on competitive positioning; understanding comparative costs; and addressing issues such as cannibalization, network externalities, and globalization. The second module focuses on the analytical tools of business modeling, and the alignment of business structures and behavior to strategic concerns.
That’s my take on a potential degree program. I know this is a bit off-topic for an Enterprise Architect, but it is good to illustrate a wish list sometimes.