Talk:Systems architect/Archive 1

Archive 1

Arbitrary section header

This is a much better definition for software systems architect!

To understand better the role of a systems architect and the role of a software systems architect (or, just software architect)— which is what your definition mainly seems to refer to— see the new definition for systems architecture.

I have taken the liberty of copying your definition to a new phrase entitled, "Software architect." (with Software systems architect redirected to it.)

I will (shortly) supply a new definition for systems architect. Completed; comments solicited.

Sorry if I seem to be coming on too strong; I am just getting the hang of wikipedia and how to send individual and/or private messages (or, any messages, for that matter).

FWIW, I was a systems architect for the last 15 years or so (at the U.S. DOT/FAA).

Note: I have broadened the definition of system and architect and architecture, rewritten the definition for data processor and acceptance test, and added a new definition for systems architecture. I hope, eventually, to bring all (or most) of the computer-related terms into some conformity. Please especially read my stuff for readability; I tend to lapse into jargon when I try to strictly define computerese. I am (blush) a geek!

This is the Background for the definition of a systems architect.

>Still needs editing; suggestions welcomed<

[In the beginning, we were just happy to get the parts to work. The emphasis was on building the parts right— on making the hardware and the computer control program reliable; the compiler able to produce fast and compact code; and the data management powerful and error-free. Ideally, someone produced the knobs and switches and the application software that provided a tolerable interface with the user. That someone may have satisfactorily tuned up any components that the user didn't like. More often, the user was persuaded or coerced to live with the system as engineered, with perhaps one or two half-hearted attempts to correct the worst goofs.]

Large systems architecture was developed as a way to handle systems too large for one person to conceive of, let alone design. In modern societies, large systems are rapidly becoming the norm, so the requirement for large systems architects has become critical.

The provision of needed services to the user is the true function of an engineered system. As systems' emphases move away from simple hardware and software components, the narrow application of traditional systems development principles was found insufficient— the application of the more general principles of systems, hardware, and software architecture to systems design came to be needed. An architecture is a simplified model of the finished end product— its primary function is to define the parts and their relationships to each other so that the whole can be seen to be a consistent, complete, and correct representation of what the user had in mind— especially for the computer-human interface. It is also used to insure that the parts fit together and relate in the desired way.

Most engineers are specialists. They know the applications of one field of applied engineering science intimately, apply their knowledge to practical situations— that is, solve real world problems, evaluate the cost/benefits of various solutions within their specialty, and ensure the correct operation of whatever they design. Architects are generalists. They are not expected to be experts in any one technology but are expected to be knowledgeable of many technologies and able to judge their applicability to specific situations. They also apply their knowledge to practical situations, but evaluate the cost/benefits of various solutions using different technologies, for example, hardware versus software versus manual, and assure that the system as a whole performs according to the user's expectations. A good architect is a translator between the user and engineers— and even among just engineers, but of different specialties. A good architect is also the principal keeper of the user's vision of the end product— and of the process of deriving requirements from and implementing that vision.

Engineers as a group do not have a reputation for understanding and responding to human needs comfortably or for developing humanly functional and aesthetically pleasing products. Architects are expected to understand human needs and develop humanly functional and aesthetically pleasing products.

An architect planning a building works on the overall design, making sure it will be pleasing and useful to its inhabitants. While a single architect by himself may be enough to build a single-family house, many engineers may be needed, in addition, to solve the detailed problems that arise when a novel high-rise building is designed. If the job is large and complex enough, parts of the job may be sub-architected. That is, if we are building a housing complex, we may have one architect for the complex, and one for each type of building, as part of an architectural team.

Layering the architecture is important for keeping the architecture sufficiently simple at each layer so that it is comprehensible to a single mind. As we ascend layers, whole systems at lower layers become simple components at the higher layers, and may disappear altogether at the highest layers.

It is also necessary to distinguish between the architecture of the user's world and the engineered systems architecture. The former represents and adresses problems and solutions in the user's world. It is principally captured in the computer-human interfaces (CHI) of the engineered system. The engineered system represents the engineering solutions— how the engineer proposes to select and combine the components of the technical infrastructure to support the CHI. In the absence of an architect, there is an unfortunate tendency to confuse the two, since the engineer thinks only in terms of hardware and software, but the user may be thinking only in terms of solving a problem of getting people from point A to point B in a reasonable amount of time and with a reasonable expenditure of energy, or of getting needed information to customers and staff. A systems architect is expected to combine knowledge of both the architecture of the user's world and of (all potentially useful) engineering systems architectures. The former is a joint activity with the user— the latter is a joint activity with the engineers.

Large automation systems also require an architect and much engineering talent. If the engineered system is large and complex enough, the systems architect should defer to a hardware architect and a software architect for parts of the job, although they all may be members of a joint architectural team. But the architect should never be viewed as an engineering supervisor.

Determining what the users actually want, rather than what they say they want, is not engineering— it is an art. An architect does not follow an exact procedure. S/he communicates with clients in a highly interactive way— together they extract the true requirements necessary for the engineered system. The architect must remain constantly in communication with the end users. Therefore, the architect must be intimately familiar with the user's environment and problem. (The engineer need only be very knowledgeable in the potential engineering solution space.)

A building architect uses sketches, models, drawings. An automation systems (or software or hardware) architect should use sketches, models, and prototypes to discuss different solutions and results with users. An early, draft version of the user's manual is invaluable, especially in conjunction with a prototype. A set of (engineering) requirements as a means of communicating with the users is explicitly to be avoided. A well written set of requirements, or specification, is intelligible only to the engineering fraternity, much as a a legal contract is for lawyers.

The user should view the architect as the user's representative and provide all input through the architect. Direct interaction with a project engineer is not recommended since the chance of mutual misunderstanding is very high. The user requirements' specification should be a joint product of the user and architect: the user brings his needs and wish list, the architect brings knowledge of what is likely to prove doable within cost and time constraints. (If there is a sponsor other than the user, the sponsor must interact only with the architect and/or the users.) This is also the best time to write the acceptance test. That way, the user will be absolutely clear about what s/he is getting. It is also a safeguard against untestable requirements, misunderstandings, and requirements creep.

The architect should sub-allocate the system requirements to major components or subsystems that are within the scope of a single hardware or software engineer or engineering manager. (If the item is sufficiently large and/or complex, the chief architect will sub-allocate portions to more specialized architects.) Ideally, such a component/subsystem is a sufficiently stand-alone object that it can be tested as a complete component, separate from the whole, using only a simple testbed to supply simulated inputs and record outputs. That is, it is not necessary to know how an air traffic control system works in order to design and build a data management subsystem for it. It is only necessary to know the constraints under which the subsystem will be expected to operate.

Acceptance tests always remain the principal responsibility of the architect(s). It is the chief means by which the architect will prove to the user that the system is as originally planned and that all subordinate architects and engineers have met their objectives. Large projects tend to be dynamic, with changes along the way needed by the user (e.g., as his problems change), or expected of the user (e.g., for cost or schedule reasons). But acceptance tests must be kept current at all times. They are the principal means by which the user is kept informed as to how the final product will perform. And they act as the principal goal for which all subordinate personnel must design and test for.

The development of the first level of engineering specifications is not a purely analytical exercise and should involve both the architect and engineer. If any compromises are to be made— to meet constraints like cost, schedule, power, or space, the architect must insure that the final product and overall look and feel do not stray very far from the user's intent. The engineer should focus on developing a design that optimizes the constraints but ensures a workable and reliable product. The architect is primarily concerned with the comfort and usefulness of the product; the engineer is primarily concerned with the producibility and usability of the product.

Because requirements evolve over the course of a project, especially a long one, an architect is needed until the system is accepted by the user: the architect is the best insurance that all changes and interpretations made during the course of development do not compromise the user's viewpoint.

A good architect ensures that the system, however complex, is built upon a relatively simple and "clean" concept at each level or layer— easily understandable by everyone, especially the user, without special training. As user needs evolve, (once the system is fielded and in use), it is a lot easier subsequently to evolve a simple concept than one laden with exceptions, special cases, and lots of "fine print."

Many commercial-off-the-shelf hardware and software components may be selected independently according to constraints such as cost, response, throughput, etc. In some cases, the architect can already assemble the end system unaided. However, the architect may still need the help of a hardware or software engineer to select components and to design and build any special purpose function. The architects (or engineers) may also enlist the aid of specialists— in safety, security, communications, special purpose hardware, graphics, human factors, test and evaluation, quality control, RMA, interface management, etc. An effective systems architectural team must have immediate access to specialists in critical specialties.

A good architecture may be viewed as a 'partitioning scheme,' or algorithm, which partitions all of the system's present and foreseeable requirements into a workable set of cleanly bounded "buckets" with nothing left over. That is, it is a partitioning scheme which is exclusive, inclusive, and exhaustive. A major purpose of the partitioning is to arrange the elements in the buckets so that there is a minimum of communications needed among buckets. In both software and hardware, a good bucket tends to be seen to be a meaningful "object." Moreover, a good architecture provides for an easy mapping to the user's requirements and the validation tests of the user's requirements. If everyone keeps to the religion, a mapping also exists from every least element to every requirement and test.

A good architect always develops a robust architecture. The major benefit of a robust architecture is that it has forward compatibility and extensibility Extensibility means that the system has been so architected that the design includes all of the hooks and mechanisms for expanding/ enhancing the system with new capabilities without having to make major changes to the infrastructure. The good architecture provides the design principles to ensure this— a roadmap for that portion of the road yet to be built. Note that this usually means that capabilities and mechanisms must be built into the initial delivery which will not be used in that delivery and, indeed, may never be used. This excess capability is crucial for avoiding early obsolescence. But the architect may need to spend more effort defending these "frills" from cost conscious customers and engineers focused on the bottom line and "here and now" than for anything else.

—Preceding unsigned comment added by Normxxx (talk • contribs)

formality

Good content, but the style needs to be formalised. It's preferable to have an assertive definition then and a supporting paragraph (or several) in the introduction, then proceed with sectioning. Parentheses and slashes should be used sparingly, IMO. -- Natalinasmpf 00:35, 26 December 2005 (UTC)

Don't see how the introduction can be more assertive! It states exactly what the systems architect IS responsible for in 9 bullets! (Use of "is" in such a sentence is roughly the equivalent of "I will be" or "he shall be.") It is an assertion without benefit of exception, except where stated.

The Background explanatory text is a little more recondite; but that's the nature of things— as you drill down, things get ever fuzzier. —Preceding unsigned comment added by Normxxx (talk • contribs)

198.97.67.59

If you stick to 'exclusively' precise and unambiguous language, you get a spec that is "unintelligible to the average user." In this world, you can't have it all ways. ⇒ _normxxx| ^talk ⇒ email 01:30, 3 February 2006 (UTC)

---

Wherever you have imprecise and ambiguous language, the ability to have a sign off by a customer on the proposed architecture decreases. The result is that you may end up, just to go to extremes here, building a factory for a Boeing 747 that doesn't actually meet the customer's needs. That, obviously, can be expensive. When dealing with spiral development, imprecise and unambiguous language is a necessary feature. But spiral development only works when the cost of requirements gathering is higher than the cost of development. When that isn't the case, Vee diagram development should probably be used and that means that precise and unambiguous language is required. One of the system's architects primary duties is to communicate the proposed architecture precisely and unambiguously to all customers/stakeholders to the extent that is needed for their (the customer's/stakeholder's) scope.

-BN —Preceding unsigned comment added by 198.97.67.56 (talk • contribs)

---

But spiral development only works when the cost of requirements gathering is higher than the cost of development.

Or, when the final requirements are not yet known, so rather than have a lot of open ended (imprecise) requirements, you opt to go with an approach that allows you to develop and discover the requirements as you go.

A "customer friendly" spec need not and cannot have only the bare bones, precise (operationally defined) set of engineering requirements— else it will read like a legal document— the bare bones must be covered in sugar coated, user oriented "explanatory" language. But the actual engineering requirements must be easily (preferably mechanically) extractable from the full spec.

One of the system's architects primary duties is to communicate the proposed architecture precisely and unambiguously to all customers/stakeholders to the extent that is needed for their (the customer's/stakeholder's) scope.

Right; which is why I always have insisted that (1) the Acceptance test be written contemporaneously with the requirements and signed off on by all stakeholders at the same time as the requirements are signed, or shortly thereafter; and (2) the user is preferably kept informed of what is evolving (including requirements) by using a preliminary user's manual and prototype. If a program is big enough to afford a systems architect, it should be big enough to support a prototype. Moreover, each and every change in requirements must be immediately reflected as a corresponding change in the Acceptance test, and everyone must sign off on that.

Sounds like you're an SE or SA; am I right? —Preceding unsigned comment added by Normxxx (talk • contribs)

---

Or, when the final requirements are not yet known.

No systems architecture can start off with an accurate model of the real problem (notice that I said "accurate", not "precise"). Vee diagrams can accomadate such lack of accuracy - if they couldn't, they'd be useless. Further, the precision implied in the use of Vee diagrams enables the stakeholders to coordinate not only when changes to the requirements definition aren't occuring, but more importantly when they are. Whether to use a spiral or Vee diagram development is all about the cost of requirements gathering vs. the cost of development.

If a program is big enough to afford a systems architect, it should be big enough to support a prototype.

Sometimes it isn't possible to build a useful prototype. The cost of building the prototype may be so great compared to building the actual system that it doesn't make sense to build the prototype. The act of creating the prototype may change the system it is suppossed to act upon. Building a new dam may change traffic patterns in a way that a prototype can't predict. Consider also, the Hawthorne effect.

else it will read like a legal document

There are two issues here. One is the need to protect yourself from the problems of imprecise communication with the stakeholders. The other is the fact that the precision can be pushed down to lower and lower levels of the requirements document (that is, sub-requirements, etc.). A stakeholder may see at the top level that a requirement is for a lunar rover to make a 180 turn within a 10 foot radius measured such that the front bumper and the initial location of the back bumper lays along an imaginary line and so does the back bumper/initial location of the front bumper. That's precise and unambiguous. Decomposing that may lead to a new set of requirements which are, each, likewise precise and unambiguous and traceable to the upper level requirement. Ad nauseum.

Sounds like you're an SE or SA; am I right?

I just finished my first semester in the Systems Architecture and Engineering Master's program at the University of Southern California. I'm too green to call myself an SE or SA yet. Call me, at best, an SE/SA in training. —Preceding unsigned comment added by 198.97.67.56 (talk • contribs)

Proposed merge

• Support — see my comments on Talk:Software architect --Allan McInnes (talk) 22:49, 6 March 2006 (UTC)

It is not the software that build the information systems

I think it will be wrong to call systems architect as a software architect. There are a lot of professionals who are designing infrastructure/network/security systems without the software architects. Software Architecture is a sub topic for Systems Architecture as Infrastructure Engineering is. —Preceding unsigned comment added by 198.252.200.253 (talk • contribs)

Yes, that would be the point of merging the content of Software architect into System architect. Most of the current content is identical (which would make the merge fairly straightforward), and the differences between the two can be delineated in a section of the System architect article devoted to the subtopic software srchitect. --Allan McInnes (talk) 18:47, 9 March 2006 (UTC)

I heartily disagree with merging; I think it would be maximally confusing for the reader. I started life as a hardware engineer (analog computers in the '50s), switched to software (in the '60s and '70s) and finally to systems architecture (with the FAA, in the late '80s and '90s). I will admit that software is the tail that wags the dog, but SE is logically primary.

Nevertheless, the software engineer/architect should never be thought of as a subordinate of the SE/A. Each has their own role to play. You can get into a lot of trouble if the SE/A takes it upon himself to "instruct" the SWE/A in how to do his job! The SE/A should be primarily interested in the ilities, and capable of assuming many of the functions which do not warrant a full-time specialist engineer. He is also concerned in getting the specialist engineers (including software and hardware) to work together (i.e., off the same sheet of music). The distinctions should not be minimized. (Stop thinking in terms of using 'efficient' functional algorithms for definitions!)

Generally speaking, systems that use general purpose computers and/or do not require a great deal of special hardware do not need or use a SA— they use a SWA instead— but this is not simply a different title; a SE/A must be comfortable with all aspect of the system, including the hardware. (And don't think a SWA retread is ever comfortable with hardware, though in this software dominated world, the reverse is often true.) ⇒ _normxxx| ^talk ⇒ email 08:26, 10 March 2006 (UTC)

One of the biggest reasons why the merger shouldn't happen is that there are systems architects who don't work at all with IT except for using it as a tool. For example, the architecture of UPS (in how it transports goods) was an act of systems architecture. —Preceding unsigned comment added by 198.97.67.58 (talk • contribs)

Didn't know that. I'm impressed. ⇒ _normxxx| ^talk ⇒ email 22:25, 10 March 2006 (UTC)

Two points:

1. Making one topic subordinate to another (simply because they share many common features) does not imply that the jobs are subordinate. This is an encyclopedia, not an org chart.
2. If there really is the substantial difference between SA and SwA that you believe there is, then please make that clear in the SwA article (which I note that you have mostly been responsible for). The reason the merge was proposed was because the description of the current coverage of the two topics appear almost identical, with minor differences that could be better covered in a section of a more general SA article (which might cover SwA, hardware architects, building architects, and the architecting of any other type of system you might conceive).

--Allan McInnes (talk) 16:20, 10 March 2006 (UTC)

It seems to me that one could argue, using the same logic you have, that we could have one page called "science" with different sections on that page for "physics", "chemistry", "biology", "astronomy", "geology", etc. After all, their methods have certain core similarities and there is some substantial bleed over from one science to another.

The reality is that, while systems architecture is an umbrella term, there are substantial differences between the different subtypes - differences as significant as between biology and psychology or cosmology and chemistry. For example,where do we begin to list the differences between cognitive architectures and the architecture of traffic systems? Where do we begin to list their similarities? To make it a little more technical, how should we distinguish between those systems whose interfaces are hard (such as accounting systems) vs those that are soft (such as political systems or knowledge systems)? Those systems whose cost of requirements gathering is greater than the cost of development (such as with software) and those for whom its the other way around (such as with hardware)? Very respectfully, when you start really understanding systems architecture you are going to realize that, as I said, creating different subheadings for the different categories makes as much sense as restricting "physics" to a subheading of "science". And because of all of this, there are going to be specialized tools which are appropriate in the field of software architecture which aren't appropriate to the overall field of systems architecture (just as a microscope might be useful in biology, but not in science as a whole - which would include psychology, economics, etc. where a microscope has no purpose).

A good example of a specialized tool used in software architecture which doesn't work so well in systems architecture is UML. A revision of it called SysML is being created for it to have applicability in the greater Systems Architecture body of knowledge. —Preceding unsigned comment added by 198.97.67.56 (talk • contribs)

Very respectfully, what I am saying is that the current Software architect article does not reflect the substantial differences that you are asserting. If the physics article looked basically identical to the science article, then I would also suggest a merger of physics into science. However they do not, so such a merger is not an issue. What I am suggesting is that either

1. The System architect and Software architect articles should be merged (I am apparently not the only one who feels this way — I didn't propose the merge, I merely support it).
2. The Software architect article should be substantially revised to reflect the differences that you are suggesting exist.

Note that I'm not suggesting that the articles should be permanently merged. If the Software architect section of a merged article eventually grew large enough, it would make sense to spin it off into a separate article again. --Allan McInnes (talk) 19:42, 10 March 2006 (UTC)

I think we both agree on two things. One, the software architect page needs more evolution. It is poorly written and does not distinguish that topic from systems architect all that well. Two, the software architect page needs to be developed by subject matter experts in the field of software architecture. As such, your legitimate concerns regarding the poorly developed software architect page need to be addressed on the software architect discussion page - not here. I am not a software architect. My area of interest is enterprise systems architecture. As such, while I acknowledge that the software architect page needs more development, I am not the person to do it. —Preceding unsigned comment added by 198.97.67.56 (talk • contribs)

I do not really majorly object to a merger if it is done very carefully, so as not to confuse the reader. (I tried to do that with architecture, but essentially got kicked off by the 'traditionalists'— the building architects) From a definitional point of view, the two are almost identical; but from a practice point of view, nada! However, please do not attempt a merger until we have figured out what to do about Technical architecture[1][2][3][4][5]. Apparently, that is an attempt to define an IT view sans software or hardware, or an overview which includes all but the kitchen sink (but, in either case, the Wiki definition is wrong!) and seems to relate more to an enterprise architecture framework (sounds like your bailiwick). Sorry to complicate things further, but such is life. ⇒ _normxxx| ^talk ⇒ email 22:25, 10 March 2006 (UTC)

You said "from a definitional point of view, the two are almost identical". I seem to be having trouble in clarifying the point that they are NOT almost identical definitionally. Systems architecture is an umbrella term which includes the study of many systems which have nothing to do with software architecture - such as political systems and organizational systems.

How about if we add the following to this article? "Systems architects may work with a variety of systems including (and this is not a definitive list), manufacturing systems (such as factories), social systems (such as political systems), software and information technology systems (such as intranets), and collaborative systems (such as charity services). Many real world systems are systems of systems and, so, may fall into several of these categories." —Preceding unsigned comment added by 24.164.94.116 (talk • contribs)

We are apparently talking past each other here. I am fully aware that systems architecting encompasses more than just software. The problem is that the current Software architect article reads as if a software architect is a systems architect who happens to focus on software (in fact, it uses substantially the same text as the Systems architect article). That being the case, it seems reasonable to merge what little alternative content the Software architect article contains into a section within the umbrella System architect article that discusses the software architect specialization of SA. If there are substantial differences in the two that wouldn't warrant a merge, then please clarify in the Software architect article (although, from my own reading of references on software architects it seems that they view themselves as systems arhcitects working on software, and even reference Rechtin and Maier on occassion). --Allan McInnes (talk) 17:56, 11 March 2006 (UTC)

We aren't talking past each other. I was responding to nomxxx, whom I was quoting.

So, what benefit do you see in merging the two articles? (That is, other than "because we'd have one article instead of two"?) —Preceding unsigned comment added by 24.164.94.116 (talk • contribs)

Ok. I'd missed the relevant section of Normxxx's last comment, but I see it now. As for the benefits of a merge, I see them as follows:

1. It eliminates substantial duplication of content between the two articles (have you compared Software architect to System architect?)
2. It makes the relationship between systems architecting and software architecting very clear (i.e. the one is effectively a specialized subset of the other - at least that's the impression I have gathered from the literature — such as Worldwide Institute of Software Architects - Role of the Software Architect and SEI - What are the Duties of a Chief Software Architect? — on software architecting)
3. It allows all of the common features of the various specializations of systems architecting (such as software architecting and enterprise architecting) to be covered in one place (and therefore better maintained), while also permitting the differences (such as they are) to be explained in detail.

As it stands right now, I can't see much that would make the Software architect article large enough to warrant a separate article. Of course, that may change if someone more content on the explicit differences between software architecting and systems architecting to Software architect.

Aside: please sign your posts — it makes it much easier to keep track of who said what.

--Allan McInnes (talk) 20:08, 11 March 2006 (UTC)

1. "It makes the relationship between systems architecting and software architecting very clear" A far better way to do that is to have a section on the systems architecting page which lists various systems (the same way that the page on science lists various sciences) while maintaining a seperate page for each of those various systems (just like physics has its own page).
2. "It allows all of the common features of the various specializations of systems architecting to be covered in one place." That's the role of the systems architecting page as it exists now. "While also permitting the differences to be explained in detail." Then why stop with software architecture? Why not reduce civil architecture, urban planning, manufacturing, cognitive architecture, etc. to subheadings on the systems architecture page?
3. "As it stands right now, I can't see much that would make the Software architect article large enough to warrant a seperate article." I agree. I suggest that it be merged, for the time being, with Software architecture. —Preceding unsigned comment added by 24.164.94.116 (talk • contribs)

I agree that it would ultimately be preferable to have separate pages for various kinds of systems. However:

1. That doesn't mean that it would be wrong to have an overview of the sub-topics of systems architecting, along with a pointer to the appropriate main article, in the System architect article.
2. I think that whatever content can be salvaged from the Software architect article would provide a good starting point for such an overview (with the eventual possibility of spinning out into its own article as the section grows).

That said, it seems we agree that the Software architect article probably needs to be merged somewhere. Maybe Software architecture would be a better location. I'd be ok with implementing either alternative. --Allan McInnes (talk) 20:58, 11 March 2006 (UTC)

References

IMHO, this article sorely needs references. There's a lot of (what appears to be) opinion in there that could be construed as original research or POV pushing. I'd suggest that, at a minimum, there should be a bunch of references to something like Rechtin and Maier's text to back up specific assertions about the role and responsibilities of the systems architect. --Allan McInnes (talk) 22:55, 6 March 2006 (UTC)

I agree; but I disposed of my SE library shortly after I retired, so I will defer to someone with good reference material. ⇒ _normxxx| ^talk ⇒ email

Altered merge proposal

I have altered the merge tags on Systems architect and Software architect to clarify the fact that the proposal is to merge content from Software architect into Systems architect. That is, to treat software architecting as a subset of systems architecting, and describe any specializations embodied by the software architect role within this article. It is not an attempt to claim that systems architecting is identically equal with software architecting. --Allan McInnes (talk) 18:05, 11 March 2006 (UTC)

All architecting is fundamentally similar (including building architecture). What breakouts do you propose (besides software, i.e., software systems architect)? How about hardware systems architect? And, if not, why not? We could also backup and include some of those "Principles of Architecture" (which we trashed; I saved a copy)— but with suitable examples.

(I thought those references you put on the SWA page were just great! Except that, your last writer got the early history of computing and programming completely scrambled! In particular, programmers were never called 'systems operators'! They would have died first! Operators were the semi-skilled, H.S. grads who were hired to run general purpose computers, change tapes, feed in the punched card decks, etc. Programmers were without university degree only on the business side, which early on invented the analyst to frame and solve business problems in a sufficiently logical way for programmers to understand. Special purpose (non-business) computer programmers always were degreed, though many were not E.E.s. Software engineer was a term invented by DoD so they could keep the two types of programmers distinct! —trust a congressperson or administrative type to openly question why one kind of programmer was earning five times the salary of the other. Aren't all programmers interchangeable? So we added SWEs and analyst/programmers, etc.)

Part of the problem (confusion?) is the umbrella term we will need to use. Systems architect is actually ideal from a definitional POV, but the SA role (in that case) is actually that of General systems architect— except that, I have never once heard that title used!

P.S. No one has yet said what we are to do with Technical architecture.⇒ _normxxx| ^talk ⇒ email 00:34, 13 March 2006 (UTC)

How to classify the various types of architect is going to depend on what kind of taxonomy for systems we use (and we are going to establish such a taxonomy first). There are several different possible taxonomies; open vs. closed, natural vs. man-made, acquired vs. developed in house, those with hard interfaces vs. those with soft interfaces, etc. Whichever taxonomy we use is going to make some types of architects look more similar than they are and others look more different than they are.

So, my recommendation is to list various characteristics (like those I just did) and then point out what characteristics various types of architects have (for example, software architects work with systems which are closed, man-made, developed, and have hard interfaces while political systems architects deal with systems which are open, natural, acquired, and have soft interfaces). Looking back on that, that won't work because the software architect may be given a task to further develop an existing software system using an open protocol for web services on the internet and the political systems architect may be given the task of developing a political system for a mmorpg game in its initial development. —Preceding unsigned comment added by 24.164.94.116 (talk • contribs)

...political systems architects deal with systems which are open, natural, acquired, and have soft interfaces...

I fail to see how political systems are "natural". I suppose some are "emergent" rather than constructed. But they are, pretty much by definition, man-made, since it's people making the rules that embody the system.

Anyway, ignoring that point and pressing on: Wikipedia has a policy of no original research. So if we are to use a taxonomy, it should probably be one that is already in existence, and readily citable in the literature. Better yet would be to skip the taxonomy, and have an existing reference for whatever architect classification scheme ends up being adopted. --Allan McInnes (talk) 03:42, 13 March 2006 (UTC)

A taxonomy or "architecture of architectures" won't do. You have both managed to illustrate why in your opening arguments! If we did try to adopt such an approach, we'd just spend all of our time wrangling over the bounderies and defintions. Clearly, when a software systems architect is running the show (when using a general purpose computer and a minimum of hardware), s/he is doing General systems architecture rather than explicit software systems architecture. As an engineer and architect, I have crossed more bounderies than I care to remember (hardware, software, applications, general systems, open systems, closed sytems, natural, unnatural— you name it). Moreover, there are no clean boundaries in practice, e.g., between 'open' and 'closed' systems. A lot of 'open' software systems architects would feel mightily put out to learn they were working on 'closed' systems! (I can hear it now; "By whose definition!?!")

What I tried to do at first (when I came up with the separated definitions), was simply to recognize the kinds of self-identifications architects are prone to. I would (at this juncture) avoid all non-technical architects— simply because most such do not view themselves as architects! So, that avoids a whole other fight. ⇒ _normxxx| ^talk ⇒ email 04:49, 13 March 2006 (UTC)

My point about WP:NOR was intended to answer the issue of By whose definition? — the answer being "the definition of that reference over there..." or words to that effect. That said, I'm not actually aware of any classification schemes for architects in the literature, and I'm skeptical that any one scheme would work. Frankly, I think that the boundary between different kinds of systems architect is probably quite fuzzy.

OTOH, so too are the boundaries between (for example) physics and chemistry. But, those terms are in common use, and weren't arbitrarily invented for Wikipedia. So I would suggest that if there is to be any kind of "breakout" of specialized systems architects, it be done in based on terms that are already in common use, and for which we can point to existing literature that uses them (thus allowing us to avoid problems with WP:NOR). The obvious categories that I can think of off the top of my head are software architect [6][7], enterprise architect [8][9], naval architect [10],[11], and perhaps political systems architect [12] (although Googling for the term "political systems architect" produces 0 hits). --Allan McInnes (talk) 05:59, 13 March 2006 (UTC)

Altered merge proposal, II

ALLAN: As a rapidly aging "keeper of the records," I can tell you right now that there are no clean definitions for any of the working categories; they just "grewed," (like Topsy, from Uncle Tom's Cabin). For the first thirty years or so, very large systems and software were such an American monopoly that we were able to force our definitions onto the World community. But that is no longer true; especially now that academia has gotten into the act and is increasingly defining distinctions. Since the '80s, therefore, there has been a steady drift apart. So if Wiki is an International encyclopedia, we will have to be very careful in where we draw the lines, especially even among engineering communities of the English speaking countries (including, e.g., India).

Here, for example, is a set of definitions from the Public Works and Government Services, Canada:

Category Descriptions

Technology Architect (TA)
Duties (General)
Duties of Hardware Architect
Duties of Software Architect
Duties of Communications Architect
Supervision

Duties (General)

•    Develops technical architectures, frameworks and strategies, either for an organization or for a major application area, to meet the business and application requirements;
•    Identifies the policies and requirements that drive out a particular solution;
•    Analyses and evaluates alternative technology solutions to meet business problems;
•    Ensures the integration of all aspects of technology solutions;
•    Monitors industry trends to ensure that solutions fit with government and industry directions for technology.

Duties of Hardware Architect

•    Reviews computer software systems and data requirements as well as communications and response needs and devises computer hardware configurations to support them;
•    Develops techniques to improve system throughout and optimize hardware utilization;
•    Evaluates computer hardware systems relative to their ability to support specified requirements and, by determining potential and actual bottlenecks, improves system performance through recommended hardware changes;
•    Should be well versed in hardware compatibility, and has participated in the design of real-time or remote access systems and has a working knowledge of process control and/or large timesharing hardware systems.

Duties of Software Architect

•    Reviews computer software systems and data requirements as well as communication and response needs and determines operating systems and languages needed to support them;
•    Analyses computer programs in terms of hardware and operating system compatibilities and utilization;
•    Should be familiar with compilers and other language translators and can determine costs for converting computer programs from one language or machine to another;
•    Given the constraints of the operating system and the hardware, can structure software programs to operate within the environment; Improves software systems efficiency through recommending better utilization of operating system capabilities;
•    Minimally, the software specialist has participated in the design of one operating system and has working knowledge of the systems of other manufacturers;
•    Has acted as a systems analyst and programmed assembly language as well as several higher level languages;
•    Should be familiar with queuing techniques and job sequencing controls within a multiprogramming environment;
•    Should be familiar with Artificial Intelligence, Expert Systems and Neural Networks.

Duties of Communications Architect

•    The Communications specialist is technically competent in the area of data communications and transmissions and analyses computer software systems, data requirements, response times and computer hardware configurations relative to the communication and data transmission requirements;
•    Reviews communications local area networks and wide area networks as to their ability to support data processing requirements;
•    Recommends changes to transmission networks, both in terms of hardware devices and switching point required to improve network performance;
•    Has a working knowledge of coding and error detection methodologies;
•    Has participated in the analysis, design, and implementation of communication networks including data processing transmissions.

Supervision:

May work independently or under the general supervision of a Project Director; Directs the work of other technology consultants.

But I really liked your serrendipitous idea of 'googling' to establish the legitimacy of categories!

You mention an affiliation with New Zealand, but you don't say where you are going to school. I ask because, if it is any place other than the U.S. (or maybe even in the U.S.), I think you might try to get some interest or input from your (non-American) professors. The historical context is invaluable; you will not appreciate it at your age, but as a bonafide nerd, I have had to (painfully) come to terms with the fact that it is people relationships and people problems that drive this world (yes; even in engineering!) That's why human-type engineers are in no great danger of being replaced by robot engineers any time in the near future! ⇒ _normxxx| ^talk ⇒ email 20:09, 13 March 2006 (UTC)

Normxxx, I have been educated in both New Zealand and the US, and have worked as a software engineer, electrical engineer, and systems engineer in the US. I am very familiar with the people aspects of engineering, having led multi-disciplinary design teams on several national space systems (and if negotiating the demands of government customers when it comes to national assets doesn't constitute a "people problem" in engineering, I don't know what does :-) --Allan McInnes (talk) 20:43, 17 March 2006 (UTC)

⇒⇒That sounds like a great background for this enterprise! We need a very global view to get this off right. 24.164.94.116 is right about that. ⇒ _normxxx| ^talk ⇒ email 23:49, 17 March 2006 (UTC)

That list doesn't mention soft systems architects or any of the non-IT systems architects. It should. —Preceding unsigned comment added by 24.164.94.116 (talk • contribs)

That was hardly an exhaustive list of systems architects— even of technical systems architects. However, I think that soft systems architects should not be combined with the technical systems architects at this time (at least, not until that area is separately flushed out). Moreover, how are you going to establish that a particular soft systems architecture field exists, if the practitioners do not so (self)identify (academic definitions don't count!) and/or if you lack suitable references (e.g., no google hits)? (I don't know of any accountants who have established major accounting systems at large coporations referring to themselves as "accounting systems architects"!) If you get too general, you can qualify most (analytical) professions as some form of systems analysis! However, I would include any non-IT(?) technology SAs out there. Problem is, IT has also grown broad enough to encompass almost any field. (How many professional fields do you know of that do not require a body of knowledge and cannot be seen as some form of information processing? Surely, an accounting system is nothing more than "IT.")

Let me tell you, when they start referring to the Boeing 777 and the Airbus as "information systems," you just know things are out of control and the tail is wagging the dog! ⇒ _normxxx| ^talk ⇒ email 23:20, 13 March 2006 (UTC)

Its been my experience, especially when looking through Monster.com and Dice.com that a lot of people associate systems engineering with the MCSE and, by extension, systems architecture exclusively with IT. That's a big problem. Its fine to point out how many people misconstrue what it is that systems architects do and what they are, but when it comes to the rubber meeting the road, we need to use actual hard core sources. We do that by looking at the classic works of systems architecture. I'd start with the academic literature on systems architecture as a basis for determining what should be considered as branches of systems architecture. One of the Bibles, so to speak, of systems architecture is Rechtin's Systems Architecture: Creating and Building Complex Systems which discusses Manufacturing Systems, Biological Systems, and Economic and Public Policy Systems. I'd also certainly include Senge's work The Fifth Discipline which looks at organizational systems. Maier's work includes, among other things, collaborative systems and social systems. Of course, there's civil architecture, aeronautic and avionic systems (Boeing is heavily invested in systems architecture), nautical, space (one of my recent profs is working on TSAT), and automobile architectures. There's also cargo systems (such as FedEx) and, as has already been hammered in our discussion, the various IT systems.

here's a pretty good definition of enterprise architecture (which is only one kind of systems architecture). Note that it's scope is fundamentally beyond IT. —Preceding unsigned comment added by 24.164.94.116 (talk • contribs)

a lot of people associate systems engineering with the MCSE and, by extension, systems architecture exclusively with IT. That's a big problem.

That's too bad; but it can't much be helped. People have a very strong tendency to be parochial and view the world through their own experiences as if that encompasses the entire world (or most of it), especially when they are young (present company excepted). For most of the history of computer programming, the ratio varied from 4:1 to 9:1 as between business and "engineering" or systems programming (we didn't much distinguish between types of application programmers— it was generically: Business ==> Cobol programmers and Systems or Engineering ==> Fortran/assembly language programmers). So the business world tended to represent computers and programming in the public mind and, to the extent that the two came together, business programming terminology and outlooks tended to dominate, although to this day, these types of programming inhabit almost different worlds. Many universities offer IT degrees (from the business departments) and CS degrees (from the engineering departments) still based on those historic definitions.

Early on, the engineering side co-opted the term Computer Science to dsistinguish themselves from the Business side. Somewhat later on, the Business side co-opted the term Information Science. This is unfortunate, but can't now be much helped: neither term is exclusive, and both terms could be (and have been) applied to both sides. In particular, it is very useful to look at all general systems problems as problems in models of information flow. [13]

Nowadays, the term IT has (to my mind legitimately) spread to encompass all of the computer science applications. So, better not to fight it, just go with the flow. Only, and I recognize this trait in you already, continue to insist on clean, operational definitions, however they are used. I have documented huge errors resulting in major cost overruns and slipped schedules because different people had defined (or interpreted) the same thing differently! You are very right; errors in definition and distinctions must be carefully pointed out.

The more I think about a merged page, the more it grows on me. You can start with some paraphrased sections of Rechtin E., Systems Architecting: Creating and Building Complex Systems, Prentice Hall, Englewood Cliffs, NJ, 1991, ISBN 0-13-880345-5 or, if you don't have a copy, say a more recent book of his, The Art of Systems Architecting, Second Edition, ISBN: 0849304407 about the general scope of systems architecture, then narrow down to the general principles of all technical architecture, then to the breakouts, of which there are many (but for openers, I would just break out the technical architectures). ⇒ _normxxx| ^talk ⇒ email 03:44, 16 March 2006 (UTC)

"then narrow down to the general principles of all technical architecture" Why do you want to stick to just breaking out the technical architectures for starters? That's setting out to give a skewed image of what systems architecture is. It makes no sense to me to deliberately provide a skewed image of systems architecture in an encyclopedia article. Also, I still say that we stick to the classics of Systems Architecture for our definitions. The two Rechtin sources listed so far are good. "Why Eagles Can't Swim" should be added to that list. If we don't do that, then another good alternative is to go with what INCOSE (the standards board governing systems architecture) has to say. I'm afraid that anything else is going to take us into the realm of original research. —Preceding unsigned comment added by 24.164.94.116 (talk • contribs)

Fine, if you can provide me with three or more (soft) practitioners who so self-identify. It's not NPOV if it is only the opinion of one or two academics! I could not disagree with you more about sources! Sources should stem from the people actively working in the field, not a bunch of academics! No original research does not mean you copy someone else's work; that's plagiarism.

Also, please sign your comments! ⇒ _normxxx| ^talk ⇒ email 22:11, 16 March 2006 (UTC)

I concur that Rechtin's various books are probably the best place to start for definitions, and should certainly act as a primary reference for this article. However, I disagree that INCOSE is the "standards board governing system architecture". Yes, INCOSE is the systems engineering professional society. Yes, they have a systems architecture working group. But they are not a standards body. Merely one more reference.

Other useful references include Mark Maier's presentation on "The Art and Science of Systems Architecting" (note that Mark is both the co-author of the 2nd edition of Rechtin's The Art of Systems Architecting, and the chair of INCOSE's SA working group), and the various documents on Gerrit Muller's systems architecting site. --Allan McInnes (talk) 20:36, 17 March 2006 (UTC)

Can you point to an existing poll on what self-identified systems architects in the field think systems achitecture includes? The closest I can think of is to get a statement from INCOSE. A poll done by yourself is original research. —Preceding unsigned comment added by 24.164.94.116 (talk • contribs)

Just do a google search and boil down the results! Show me even one google reference to accounting systems architect that was written by an accountant for other accountants or anyone else! And that's despite the fact that much of modern accounting takes place using software and major accounting systems reside on software. But, if you feel so strongly about soft architectures and architects, there is nothing stopping you from breaking that topic out to a separate page early on. I just don't want to muddy the waters of the main definition by straying too far from the conventional meaning of systems architect/ure. Encyclopedias are not supposed to present esoteric views as mainstream. (I happen to agree with Rechtin, BTW— but that is still a very offbrand view, especially outside of academia. Even architects are not usually comfortable with that degree of abstraction. In fact, try just convincing a (conventional) building architect that systems architects are bona fide architects! Why not do a biography of Rechtin, where you can expound on his views to your heart's content?)

P.S. In case you think Rechtin "discovered" or "invented" systems architecture, I had the title of "chief systems architect" from the early '80s on (at the U.S. Federal Aviation Agency)— before Rechtin's first book on the subject. (In the mid to latter '70s, I was a major "systems manager" and later, a "chief systems engineer.") ⇒ _normxxx| ^talk ⇒ email 23:49, 17 March 2006 (UTC)

Respectfully, I believe that if you are going to base an article on poll results, it should be a scientifically valid poll. Since original research isn't allowed, an ad hoc poll isn't acceptable. —Preceding unsigned comment added by 24.164.94.116 (talk • contribs)

You are misconstruing the meaning of "original research." a literature search for multiple references, and basing a definition on multiple references, rather than a single one, is the preferred approach. By "original research" is meant doing your own experiment and publishing the results, de novo, in the Wikipedia, or publishing anything in Wikipedia which cannot be verified by an independent reference. There is no requirement for a "scientific" poll.

Do you have a problem with adding ~~~~ after your comments? It can get quite confusing if there are a lot of unsigned comments. ⇒ _normxxx| ^talk ⇒ email 03:21, 18 March 2006 (UTC)

Since you asked me to do so, I've been trying to remember to sign all my posts. Sometimes I forget. There really are more important things to get worked up about than this. Besides, since I look for new posts in the history section whenever I look at this discussion and the history shows who has written what, I've never seen much of a point to it.

Again, its not deliberate. I just don't always remember. I think we need to clarify exactly what the central arguement is in our discussion. Do we both agree that the definition of 'systems architect' should be based on the academic literature or do you prefer that it is, instead, based on an ad hoc unscientific review of Google search results? Because if that is the real debate, we can do both. We can start off with stating what the academic literature has to say and then have a statement saying what the ad hoc Google search results say. There are 766,000 hits for "systems architect" on Google. If you exclude hits which return "Microsoft" or "MCSE", you get 497,000. How do you intend to break them all down and see which pages discuss which domains systems architects are working in?24.164.94.116

Altered merge proposal, III

24.164.94.116: I understand; I forget half the time myself. BTW, omit the <nowiki></nowicki> —they were only used by me to suppress wiki from generating my signature. Just four tildes will do.

Do we both agree that the definition of 'systems architect' should be based on the academic literature or do you prefer that it is, instead, based on an ad hoc unscientific review of Google search results?

Actually, both; which is why I am completely happy with Rechtin's very general definition up front. I think in all of these wiki definitions, you want the most precise (i.e., carefully crafted) and general definition in (1) the introductory matter, and that will come from academia nine times out of ten. This part should reflect the state of the art.

Next (2), we can then go with a somewhat modified, expanded definition which would begin to reflect the state of the practice. If we use Rechtin to start off with, we can initially break out (i.e., distinguish between) 'soft' and 'hard' systems architects. At that point, if you wish, you can continue with 'soft' architects on another, referenced page.

But continuing under the main body of "systems architects," I would then (3) go with general introductory material (for which the current definition is fine, although it certainly can be altered/expanded upon) for the 'hard' SAs; then (4) do a breakout for the different types of 'hard' SAs.

Or, do you think you can cover the 'soft' and 'hard' SAs under one set of introductory matter? I think that last would be a stretch. Remember, this latter general material should follow what SAs actually do (the state of the practice), rather than some theoretical notion of it (the state of the art). What 'hard' SAs actually do is largely captured in the current definition.

There are 766,000 hits for "systems architect" on Google. If you exclude hits which return "Microsoft" or "MCSE", you get 497,000. How do you intend to break them all down and see which pages discuss which domains systems architects are working in?

Fortunately, we are not required to do that. Here is where the genius of the wiki approach comes in. All that is required is a definition that pleases us, with sufficient references to show it is not "original" or otherwise idiosyncratic. ⇒ _normxxx| ^talk ⇒ email 22:36, 18 March 2006 (UTC)

There is a very natural transition between the state of the art and the state of the practice by looking at the characteristics of systems. Soft systems have indiscreet components (or sub systems), while hard systems have discreet components or sub systems. By looking at the various characteristics of systems (such as the degree to which components/sub systems are discreet, the degree to which a system is open or closed, the degree to which a system is pre-existing or not, the degree to which a system is natural or man made, etc.) - a breakdown of the state of the art - it leads into the challenges facing systems architects dealing with those various systems and the tools they use to address each - the state of the practice. I assure you that a skewed view of systems architecture overly focusing on IT using highly questionable statistics for support is not going to ever please me. 24.164.94.116 14:19, 19 March 2006 (UTC)

24.164.94.116: Can You Provide An Example?

There is a very natural transition between the state of the art and the state of the practice by looking at the characteristics of systems. Soft systems have indiscreet components (or sub systems), while hard systems have discreet components or sub systems. By looking at the various characteristics of systems (such as the degree to which components/sub systems are discreet, the degree to which a system is open or closed, the degree to which a system is pre-existing or not, the degree to which a system is natural or man made, etc.) - a breakdown of the state of the art - it leads into the challenges facing systems architects dealing with those various systems and the tools they use to address each - the state of the practice.

Frankly, I don't understand a word of what you have written. Perhaps you could produce an example. I think the components of accounting, economics, psychology, medicine, or even (specific forms of) entertainment are no more or less 'indiscreet', open, pre-existing, natural, etc. than anything in electrical engineering— if it were not so, it would be largely useless to try to model such using mathematical or computer models. I think these are artificial distinctions or, at the most, simply distinctions of degree. The only clear difference is that it is harder to capture such, since we have only just begun to expend serious effort in the attempt (so our fund of hard data in these areas is still pretty thin— as once was true of engineering, in its 'trial and error' days!).

[The people attracted to such 'soft' fields tend to think predominently analogically rather than analytically, whereas most scientists and engineers tend to be more balanced, through inclination and training. Nevertheless, humans as a whole are analogical thinkers— thinking analytically is largely a learned skill. (Did I mention my Ph.D. degree was in Psychology (earned mid-career) and my principal interest is in Philosophy of Science? —which latter is why I switched to Psychology, briefly; but that's another, largely irrelevant, story.) Still, take my word for it, the so-called 'soft' fields can only benefit from systematically applied analytical thinking (as the "healing arts," such as medicine, are finding out).]

I assure you that a skewed view of systems architecture overly focusing on IT using highly questionable statistics for support is not going to ever please me.

Nor would it me. My entire career has been with automation or embedded computer systems (radar, weapons systems, communications, aviation and space systems, air traffic control)— with a time out to develop a 4th generation, real-time operating system for a specially modified RCA Spectra in the early '70s (for an on-board Space systems computer— for which I also wrote the microcode for several of the computer instructions— which 'executed,' without an address counter, at the circuit level). Since I started with analog computers, I have always boasted that I was working with hard real-time systems almost a decade before digital computers were fast enough! (Sorry for the resumé, but it's been a really fun career— hope you have as much fun!)

Nevertheless, the only common thread in all of the fields you seem eager to corral into SA seems to be that each uses and processes information of some kind!

Can you produce a short piece illustrating what you mean about the 'differences between,' e.g., E.E. and say, economics? Or, pick any 'soft' and 'hard' fields.

I'm sensing a possible point of confusion. I don't want to offend you, but I do want to see if the confusion exists. You seem to be confounding scientific thinking, systems thinking, and engineering thinking. They are different categories of thinking processes. None of them is a sub part of any of the others.

As for soft systems and what they are, I believe you'll find Peter Checkland's work helpful. 24.164.94.116 22:04, 19 March 2006 (UTC) I think we should consider merging the systems architect page with the page on Systems Thinking. Specifically, I think we should expand the Systems Thinking page by including a section on systems architects vs. systems engineers and their respective tasks wrt systems in the real world. 24.164.94.116 22:18, 19 March 2006 (UTC)

I would oppose the merge you propose. SAs may practice systems thinking, but not all systems thinkers are systems architects. I suggets that it would be worthwhile to point to Systems thinking from the SA article, and similarly to mention in the Systems thinking article the existence of systems architects as users of systems thinking. But merging the two is innappropriate. --Allan McInnes (talk) 16:56, 20 March 2006 (UTC)

It is true that not all systems thinkers are systems architects. That's why I proposed having a section which distinguishes systems engineers from systems architects. What roles do you believe exists which are not systems engineers or systems architects? 198.97.67.56 19:43, 20 March 2006 (UTC)

Well, you might start with the business and management folks that were Peter Senge's target audience with his book The Fifth Discipline. --Allan McInnes (talk) 14:13, 31 March 2006 (UTC)

He was arguing for those business and management folks to act as systems architects.198.97.67.58 15:04, 31 March 2006 (UTC)

Do you have a source for that assertion? I don't recall seeing any mention of systems architecting in Senge's book. Granted, it's been a while since I last read it. OTOH, the index for my copy of The Fifth Discipline does not list "systems architect", or even "architect". Senge certainly argued for business and management folks to become systems thinkers. Are you asserting that all systems thinkers are systems architects? --Allan McInnes (talk) 04:06, 1 April 2006 (UTC)

My assertion is that if it quakes like a duck, walks like a duck, looks like a duck, etc. then its a duck. Every technique Senge discusses is a technique used by systems architects. Every philosophical principle and heuristic of his arguement is a philosophical principle or heuristic of systems architecture.

My assertion is that systems thinkers are either systems engineers or systems architects. Until I see a systems thinker who is using different techniques and philosophical principles then either a systems architect or systems engineer, I'm going to stick to that assertion.24.164.94.116 14:10, 1 April 2006 (UTC)

Er... that's somewhat circular, isn't it? "All systems thinkers are systems architects, therefore all systems thinkers are systems architects." I'm afraid I have a hard time buying that. I'm willing to stipulate that all systems architects use systems thinking. But I don't think it follows that (a) the only thing that defines a systems architect is systems thinking, or that (b) all systems thinkers are necessarily systems architects. Systems thinking is just one tool in the systems architect's arsenal (along with interpersonal communications skills, synthesis skills, and a host of others). --Allan McInnes (talk) 16:23, 1 April 2006 (UTC)

I don't think so. I start from a very simple question "what are systems architects?" I define them by how they act (forex. they focus on architecing emergent characteristics) and how they achieve that (forex. by using heuristics, design patterns, etc.) I then recognize that Senge is arguing for the same thing (focusing on emergent behaviours and using heuristics, design patterns, etc.) and, from that, I derive that Senge is arguing for managers to act as systems architects.24.164.94.116 18:02, 1 April 2006 (UTC)

Merge Proposal IV

Since there has been no further discussion on the proposed merger, I'm considering removing the proposal for merging software architect and systems architect. Are there any objections? —Preceding unsigned comment added by 198.97.67.57 (talk • contribs)

Yes, I object. The discussion was never resolved, it simply petered out. Not to mention the fact that the participants in the discussion seemed (at least to me) to be converging towards performing the merger, and retaining a single article until someone provides more (referenced) material that differentiates software architects from systems architects. --Allan McInnes (talk) 14:12, 31 March 2006 (UTC)

I'm not really sure what you were reading that looked like the participants in the discussion seemed to be converging towards performing the merger. It didn't and still doesn't look that way to me at all. I have yet to see any arguement which would make the merger make sense. 198.97.67.58 15:04, 31 March 2006 (UTC)

I was reading the several comments where various participants in the discussion agreed that the Software architect article, as it stands, contains little or nothing that differentiates it from the Systems architect article, and further agreed that the extensive similarity might warrant at least a temporary merge. --Allan McInnes (talk) 01:20, 1 April 2006 (UTC)

What do you want wrt material that differentiates software architects from systems architects?

I've brought up INCOSE, Reichtin, I could bring up Nightingale, I could bring up countless other sources. I think your mind is already made up on the issue and nothing is going to change it.

To prove me wrong, tell me what exactly you are looking for to decide whether software architecture and systems architecture are different fields. Does the fact that the only graduate school program in the nation which gives a Master's degree in systems architecture (and starting next year, the only graduate school program which gives a Doctorate in the field) grounds it in ISE rather than Comp Sci influence your opinion at all? I mean, seriously, what would it take?198.97.67.56 15:28, 31 March 2006 (UTC)

I am looking for something (anything!) that demonstrates that software architecting isn't just systems architecting carried out on software systems. I've read Rechtin's work. I've even had lunch with Rechtin, and discussed systems architecting with him. I am well aware of the USC program's roots. I've also read the various discussions of "software architecting" out there (for which I have provided several references). Even the software architect crowd references Rechtin. I have yet to see anything that indicates that software architecting is anything other than a specialization of systems architecting. Which is why I support a merger (with Software architect ultimately redirected to Systems architect). --Allan McInnes (talk) 01:20, 1 April 2006 (UTC)

If your point is simply that software architecture is a subset of systems architecture, you won't find me arguing with you. As I've said, its the same as saying that physics is a form of science. Yet, physics has its own article. Sure, you can boil all the various sciences down to the same core methodology - the scientific method - and the same core beliefs about reality - empiricism, reducibility, predictability, etc. - but still the various sciences have their own seperate articles and do not have a "then and only then" relationship with science.24.164.94.116 02:56, 1 April 2006 (UTC)

Sure. But the physics article provides substantial detail on physics-specific topics that are not covered in the science article. At present, the software architect article is practically a carbon-copy of the systems architect article, with only a few minor changes in wording. I am willing to stipulate that there is a lot that can be said about software architecting as a field in its own right. My point is that the software architect article, as it stands, does not say those things (and as such, doesn't warrant a separate article at this point). Can you provide sources or references from which we might draw "substantial detail on software-architecting-specific topics"? --Allan McInnes (talk) 04:16, 1 April 2006 (UTC)

Off the top of my head, some things which might better go into a software architect article are n-tier architecture, SOA, spiral development (though a brief comparison of it to other development styles might be appropriate in the systems architect article), UML (though it should be mentioned in the systems architect article that efforts are being made to generalize UML to SysML), basically all the tools which are used or were developed primarily by software architects -emphasizing- how they are used in relation to one another in the field (something which really doesn't belong in the articles on the respective technologies and techniques) as a result of the peculiar characteristics of applying systems architecture to the design and building of software (forex, high requirements gathering costs relative to building costs). Some of that would be touched on briefly in the systems architect article, but here it would focus on a comparative analysis whereas there it would focus on the details of how they are used and why they were developed.—Preceding unsigned comment added by 24.164.94.116 (talk • contribs)

Sounds great! If the Software architect article actually contained any of that material, I would be more than happy to retract the merge proposal. Are you going to add such material into the Software architect article? Do you have references that might be used in producing such an article? --Allan McInnes (talk) 16:29, 1 April 2006 (UTC)

I'll look for some sources. I don't know if I want to commit the level of effort it would take to write an article on software architecture. This is especially true considering that I'm studying for my Master's degree in systems architecture, not software architecture. It makes more sense to me to have a software architect rewrite the software architect article. I'd be happy to provide input in the form of a systems context for that article.

Now that the problem has been identified as not being with the systems architect article but with the software architect article and the cure has been agreed on as being a rewrite of the software architect article, how about we move this discussion to the software architect article where people most likely to do a rewrite of the software architect article can see it?

198.97.67.56 19:24, 5 April 2006 (UTC)

Based on the where this discussion ended up, I have removed the merge tag from the article. If anyone objects to this move, feel free to add the merge tag back and reopen discussions. --Allan McInnes (talk) 20:56, 13 April 2006 (UTC)