Home | Login | Recent Changes | Search | All Pages | Help

PrimingThread

back to ArchitectureSession

"It is change, continuing change, inevitable change, that is the dominant factor in society today. No sensible decision can be made any longer without taking into account not only the world as it is, but the world as it will be. . . . This, in turn, means that our statesmen, our businessmen, our everyman must take on a science fictional way of thinking." --Isaac Asimov What are our attitudes toward:

� Differences, � Distinctions, � Problems, � Opportunities, � Challenges, � Constraints, or � Changes.

How can we perceive a difference? How do we detect a difference? How do we make a distinction? How do we evaluate an opportunity? Are we able to meet the challenge? How do we feel about change? �

Architectures are time stamped. Any architectural specification must be dated. Architecture specifications are the way that we answer the questions above. Stiles

I like this concept.

"This is the architecture as of this particular moment in time."

or

"This is our changing view of what doesn't or shouldn't change." Jerry Weinberg

This could be inverted to say:

�This is our changing view of what can change (but may not), does change (whether we like it or not), or shouldn't change.� Stiles

After some thought; I would go further. We must retain an emotional grasp of the fact that some architectural specifications whose elements are dynamic are out of date before they are published. This should not mean that we throw up our hands and don't produce them. Stiles

The architectures are the mechanisms by which we may plan the evolution of the architectures and the architectural relationships.

The architectures are the mechanisms by which we may plan the evolution of the architectures and the architectural relationships to stay connected to the Ever changing Web of Being or the Vast Plains of Humanity.

Nynke

Bob, Stiles, Jerry,

"How Buildings Learn" has become one of my favorite Realms to hunt "other perspectives" on architectural issues. Count me in, please!

Nynke

PS: General Systems Theory, the Cathedral and the Bazaar and tracking Linux's development are my favorites for organizational development concerns. And Hans Christian Andersen's fairy tales and the QSM series my definite favorites for process improvements items.

Bob King,

Yes! I am interested. I am a bit conflicted these days about comparing systems architecture to building architecture, but the ideas in the word document drove me to Stewart Brand's book: How Buildings Learn. We've talking about building software that learns for 20 years now and we seem to be moving further away from this goal as time moves on. We just seem to put more and more stuff in our applications - perhaps to increase the feature list - without any help on managing all that stuff. Brand, in the aforementioned book, analyzes how some buildings have been adapted over time through their use. I would be interested the study of a particular application - say MS Word - and how it has adapted through the years by how people have used it.

Stiles

I am interested in the analogy between software / systems / business architecture and the architecture of buildings. Alexander�s �A Timeless Way of Building� talks about the context of buildings and their usage patterns. I used both MS Word and WordPerfect in their MSDOS and Windows versions and the context change to wysiwyg after a text based approach had a profound affect on my willingness to approach a writing opportunity. I am by nature a very visual person. Maybe we could study our own reactions to some common software its context, its usage, and the impact of change on us???

Nynke

I have been approached for doing some telecom risk management in the Netherlands. In the role of architect I always do a lot of risk management when I am balancing (tracking/trading possible effects of) drivers and boundary conditions in solution space. Building Big Pictures of possible connections and flow ... I served as systems architect in a project for creating the platform they will be using. The combination of "introducing new technology" with risk management (architecture), in an area I feel familiar in looks interesting. At the same time I worry about the "problem solutioning" factor. I'll be hired by the organization that built the technology.

Questions:

1. Stiles, can I see the "pressures" you have in the pix as my "boundary

conditions and drivers"?

2. Is risk management in such a context much different from my architectural

version?

3. Any (other) dangers that you can see with so little information?
4. All I have more is the names to the companies. In a setting like this

(email exchange with trusted peers) is it custom to see those as confidential?

Nynke

Yes, I'd *love* to explore what we, architects in general, can do to people in the world, especially by studying our own reactions.

- Interfaces are often made for people with NT preferences (architects and developers telling the world what a useful interface would be). I remember a column by Dan Starr, on the "controls" of applications and pre-suppositions on preferences by the makers. I could easily see that happening around me everywhere.

- Interfaces we get presented with are often contaminated with a history (backward compatability issues) resulting in unorthogonal interfaces where it is not needed. Building on what is there is important, but some things need to go. A "point of no return" business wise representing the used short term/long term balance can reflect from the state the interfaces (and functionality) are in.

- Programs are getting "more universal". As users, we get bombarded with "complete" applications and interfaces (and the subsequent required move to fatter and fatter machines). Many features in my windows applications (I have a separate such yukk machine for solving compatability issues with customers) are utterly useless for me.

- It took me a week to figure out how to get a table of contents in Microsoft Word ... Silly me.

- Coupled, integrated sales and a lot of politics in standardization committees, giving rather clownesk protocols and interfaces.

...

*Similarly Irritated Hugs*,

Nynke

It took me a week to figure out how to get a table of contents in Microsoft Word THE WAY I WANTED IT!! ... Silly me.

Jerry

>2. Is risk management in such a context much different from my architectural version?

Not at an abstract level. I suppose there are particular risks that you, personally don't know about, but I'm sure you'll be using them to brainstorm their risks.

>3. Any (other) dangers that you can see with so little information?

Just the danger of so little information. See if you can go into it incrementally.

>4. All I have more is the names to the companies. In a setting like this (email exchange with trusted peers) is it custom to see those as confidential?

I'd say it's wise to keep out the names of the companies, unless there is a particular meaning to them. If so, you can ask us to keep them in confidence. I believe you can trust this group.

*Rusty Crusty Trusty Hugs*

Nynke

Jerry,

Thank you very much, my dear Yul. It is so good to know you.

>> but I'm sure you'll be using them to brainstorm their risks.

Of course, the Hunt ...One where how skillful and respectful it is done becomes more important than what the outcome is while you do it.

> Just the danger of so little information. See if you can go into it incrementally.

Can't see how at the moment. He said he'd contact me. He will.

I met my contact and the other people in this consultant team a couple of times in the US. We have tried finding ways of working together, but found no way to make that happen, until now. This one I'll have to do for the experience, which I committed two years ago to myself to go for if the opportunity would arise.

My "job" would be to eeeh ... "do the risk management in the Netherlands. We are introducing a new methodology. I will contact you when things firm up. Uh-oh ... and telecom world's eyes are on this project.

> I'd say it's wise to keep out the names of the companies, unless there is a particular meaning to them.

What if I don't know if there would be a meaning? Irrelevant state can happen due to lack of information to solve an interesting puzzle? Gosh, that would be quite obstinate of me. And I could be very close to such a state now <snigger>. Living on the edge ...

> I believe you can trust this group.

I believe so too.

*Relaxed Puzzling Hugs*,

Stiles

Nynke,

<1. Stiles, can I see the "pressures" you have in the pix as my "boundary conditions and drivers"?>

I use the word pressure to describe both constraints (boundary conditions?) and opportunity. Pressure acts as "rationale" for change agents to initiate change within the organization of interest. The purpose of looking at organization context is to identify, in so far as possible, the sources of change and the potential nature of those changes.

Virtual hugs. Stiles

Nynke

Stiles,

>>Pressure acts as "rationale" for change agents to initiate change within the organization of interest. The purpose of looking at organization context is to identify, in so far as possible, the sources of change and the potential nature of those changes.<<

I think I understand ...

*Tracking? Hugs*,

Stiles

Nynke, I believe you do! I am including, for your review, a sample context diagram from the chapter on context in the book that I am working on. This diagram is taken at the company level for a specific set of circumstances. The numbers on the diagram are an intermediate step in the transformation process that yields a process flow. The context views are elements of what I call an Organizational Architecture. The context view is inversely transformable with the process / functional flow views of the Business Process Architecture. This view is also "flat" in the sense that it presents one layer of the organization. I have had some success using color to present a "3 dimensional" view. This diagram is important because it is grounded in the actual organization and information transfers that it participates in. Any business person who is visual can relate to it and say "Yes! That's my business." It is always my starting point for any business analysis if the organization charts are available. Enjoy! I hope you can read the attachment.

Nynke

Stiles,

>> I am including, for your review, a sample context diagram from the chapter on context in the book that I am working on.<< [snip] >> This diagram is important because it is grounded in the actual organization and information transfers that it participates in.<< [snip] >> It is always my starting point for any business analysis if the organization charts are available. Enjoy! <<

Can see its use for hunting pressures in my Big Picture for risk management. Thank you. On reviewing the sample (Good! I won't feel I owe you one!): I propose I let your sample sink in and try out filling in a couple of different views that might give us a jiggle? What I can see (just for) now is a possible

- kinesthetic translation for a strategic management view; - a road map view for quality assurance (as used in TQM); - pattern {context/event(s)/effects}diagramming view for tactical management.

Filling in would take me a couple of days, the activity really get my brain racing in seen possible connections ...

And I am entirely happy to report that I have not come across any pattern diagramming method covering the above intentions yet. Maybe we need to invent it. This type of diagramming would have to be based on a (growing) knowledge base of applied tactics with context and results, and a contact {for further, detailed information}, linking into one another where needed. The by Jerry used DOE comes very close. There is something missing ... History!!

*Pffft Hugs*,

Nynke

Stiles,

This is funny. After writing that email (took me a while), I find the one that came in later. I just read your reply ... your convergence resembles mine, or vv <grin>?

<Problem Survival & Renewal: How to make the positive feedback loops of an organization's (organism) intended adaptation to it's changing environment, it's pressures, visible from deeper within the organization?>

Exactly! We can also use the architectures to express the "detailed" nature of the desired / needed / mandated changes and the ripple effect of the changes throughout the organization.

<Problem Experiencing: How to enable learning from experience and close the internal negative feedback loop, how to make these pressures visible to the strategic management process? >

Strategic, Tactical, Operational or even project level planning and management can be enhanced by an understanding of the architectures and their relationships.

<Problem Information Overload: How to prevent information overload state of "organs"? How to manage the information flow?>

All of the displays of the architectures should be held at the set level of abstraction. This allows us to see the big picture. If the architecture metadata is stored in a database instead of just pictures then we could arrange to "drill down" at any point.

<Problem Balancing: Architecting Change? Change Architecting?>

Some of both probably.

Regards Hugs Stiles

Jerry

Nynke, et al.

>>And I am entirely happy to report that I have not come across any pattern diagramming method covering the above intentions yet. Maybe we need to invent it. This type of diagramming would have to be based on a (growing) knowledge base of applied tactics with context and results, and a contact {for further, detailed information}, linking into one another where needed. The by Jerry used DOE comes very close. There is something missing ... History!!<<

History has always added a layer of complexity to systems. Memoryless systems are always easier to debug, esp. if you KNOW they are memoryless. Unfortunately, you never really know, even for machines.

By choosing the right variables, you can get some sense of history in the Diagram of Effects. For example, you might have - number of bad experiences in recent times - number of previous data base implementations - accumulated stress ...

Of course, it's still harder to read the effects, but this is the kind of thing you do if you're actually going to make the DOE into a dynamic simulation.

back to ArchitectureSession