Architects and architecture define the means to the outcome.    The constituencies of architecture have the desire that those outcomes be consistent, are timely, and are systematic as it relates to the course of action.  The philosophies of ethics and architecture are highly intertwined.    The process of architecture involves the purposeful systemization of “something”, getting consensus on the correctness and validity of the solution in question, and how trade-offs decisions are made.   Ethics involves the systemization of what conceptually is appropriate and inappropriate conduct based on an agreed upon set of values, and the definition of mechanisms to resolve disputes.   Axiology, a branch of philosophy, point out how ethics and aesthetics come together, where “correctness / goodness” are combined with “harmony/ beauty.”    If one where to accept the premise that architecture exists to serve others, one can clearly see the linkage here around "creating the collective good” and “creating meaningful experiences.”  

So why are ethics important to socially develop architecture?    What I will address here is not the ethics of the architecture or solution in question, rather to highlight the fact we as architects have create and mold the right social environment in order to perform architecture.   The discipline of architecture is now far more team oriented, consensus driven, and making sure the “right” people are involved in decision making.   Having one architect know everything about the “ins and outs” of a particular problem or solution domain is certainly next to impossible given the complexity.    I believe many of us have been or are currently in the role of “the decider or all things related to architecture and governance.”   I personally have had to go through my own transformation which my actions and behavior have changed given the complexity of the world and the multidisciplinary nature of the work.   I could not longer do all of the architectural work on my own in a timely manner.

A significant amount of my time is squarely in negotiation mode.  No surprise that this is incredibly people intensive, personal, and sometimes very intimate.    Many individuals often do not want to completely disclose information, are unwilling to cooperate because of some fear that they be exploited, want to retain a feeling of power and control, or all of the above.   Solving hard problems is what we architects enjoy doing, because if anyone can do it, then it is not as rewarding.    Also solving hard problems is highly profitable and can bring prosperity to groups of societies to reach new potential.    But solving multiple context problems requires bringing together a diverse set of stakeholders, all with their own mental models of how to address the problem/opportunity.    

Scott Atran, a noteworthy anthropologist, recently wrote a piece in the book This Explains Everything where he says “reason itself is primarily aimed at social victory and political persuasion rather than philosophical or scientific truth.”    This sure complicates architecture.  The question for us:  How do we create the right environment for mutually agreed upon outcomes with a very diverse set of stakeholders each with their own definition of victory?   How can we make a salient point or negotiate effectively given that philosophical, scientific, or empirical evidence is not enough?    I have to come to the conclusion that the discipline of architecture is becoming more social which will require us architects to negotiate agreements and building more collaborative partnerships.   

So how do we build those partnerships?   At the start of an architectural partnership, or any partnership for that matter, is that there is some fundamental understanding of ethics, or specifically cultural values and norms between the all the parties involved.    All of these social groups with various, perhaps conflicting, motivations will have to play fairly in order to bring all vested constituencies to consistency cooperate effectively.      During a recent meeting with one of our clients, a fellow Microsoft colleague made the artful comment that, “We may cause some noses to get out of joint.”   This laid the foundation of understanding that a deeper partnership will cause more friction, and we will have to be mindful of that when perhaps certain cultural norms, values or intentions may be questioned.   The architectural partnership must be focused that all parties are executing in trustworthy a manner.   If there are incompatibilities that are related to people, process, or technology; there must be resolution mechanisms in place.   All who have “skin in the game” use these resolution mechanisms to establish the conduct and expectations to appropriately, respectfully, and timely “call the parties out” when there is matter requiring attention.   Timeliness is critical, as allowing issues to fester will have cancerous effect.  This will erode any goodwill that has been previously established, challenges the health of the relationship and undermines trust.  Establishing the foundation for how parties work together, where trust and transparency must be at the heart of architectural work.    It is important to address conflict, make critical decisions around trade-offs in a manner were parties can move quickly more forward.

Once this foundation of trust and ethics are established, then the next step is to test it through getting the parties together to construct a shared vision.    This is very hard, and many people avoid this because it is hard.    But this simple step pays huge dividends for future work.    There are numerous publications and studies on how to achieve a shared vision.  One of my favorites is the classic book from Peter Senge: The Fifth Discipline and the corresponding The Fifth Discipline Fieldbook.   The key takeaway here for architects is that these visions must be developed jointly so that all parties can get buy in.   This includes brining clarity, understanding, and foresight on who will take ownership for their contribution to the outcomes.    Also remember the groups that will often necessarily bring friction to the outcome, including legal, security, HR, operations, etc.    Getting these parties involved early on will make them part of the solution rather than bringing them late to the party where they will be frustrated.  This will require significant political capital, social currency and real investment to “fix” what in their minds is necessary.    It is also important to note that problems, opportunities, perceptions and intensions are clearly documented and communicated on how the new vision for future will deliver the anticipated results.   Building a shared vision is to get everyone’s mental models aligned that can be clearly understood by everyone.     This should not be a UML diagram, nor the classic architectural stack picture, but rather in clear verbiage, notation, and pictures that all parties can understand and can act upon. 

So we have agreement on establishing the social foundation for building architecture, we have a vision in which we have amalgamated everyone mental models (at minimum at a contextual level) for how we move forward.   The next step is determine a set of principles to guide activity.   As architects, we love architectural principles.   They are the axioms where certain aspects around architectural behavior which are obvious or self-evident easy, at least in principle.   (Please forgive the pun.)    But what are those social relationship-oriented principles?  I have recently come across a body of knowledge called Vested.  The authors suggest a mindset around “Getting to We” that define six guiding principles for defining a partnership relationship.   I have applied their concepts to the discipline of architecture.

• Reciprocity.   How do we as architects make fair and balanced exchanges?  How do we get the various constituencies to understand trade-offs around security and user experience, solution flexibility and precision, business freedom and operational discipline?
• Autonomy.   How can we promote that fact that certain decisions may be made not the interests of one group and not necessarily at the expense of another?   The goal is do what is good for the whole, and not just one individual constituency.
• Honesty.    All parties have to be clear about their intensions and experiences.    Dishonesty erodes the quality of the outcome in which all parties will be disenchanted with the results.
• Loyalty.   All parties have to be loyal to the relationship and the design of the outcome.    Change and innovation will take people out of their comfort zones, but is important to remain loyal to the outcome, the solution, and the relationship.
• Equity.     How can architects make equitable decisions?   If certain parties are willing to accept more risk around the quality of the solution, how do equitably distribute the risk and potential rewards?   Who is going to be on the hook?   The two important components of proportionality and remedies insure that parties of appropriate skin in the game, and where parties do not have skin in the game, their equity in the solution may not be distributed equally.
• Integrity.   How do we make architecture decisions consistently and how we behave with respect to the architectural processes.    This is about being predictable and setting expectations.   Minimizing randomness allows for more “reputational glue” around the discipline of architecture.

Enterprise architecture and other IT oriented architecture must go through this next step in order to build “people oriented” solutions or “people oriented” business/organizations.    If it is about creating experiences, shouldn’t we be the exemplars of how we behave in the conduct of our own work and practice?     We must continue to strive to incorporate the people dimension as part of the necessary dynamics of architecture.    Unfortunately today, very few of the current  methodologies and frameworks have any focus on how to accomplish some of the basic people things that absolutely essential to bring successful architecture to bear fruit.    No longer can we say, “do not take it personally, it just business.”   That is frankly just bulls—t, it is always personal.   The sooner we come to grips that we have to get out of our offices, cubicles, architectural methods, tools, and actually start talking to people then we will start producing architecture that has been sociallyl developed, oriented around value and ethics.

As always, I am interested in your thoughts….

While it may be difficult for us to describe enterprise architecture, many of us including myself do not have any trouble defining why it is valuable.     The business climate is changing rapidly, thoughtful business leaders are starting to recognize that there are some deep persistent problems that are not being addressed or solved.   Often in our attempts to solve or govern them, we are actually causing more harm than good.   Also when business managers believe problems are not-solvable, they actually fall back on what they know how to do:  govern through policy, procedure, and politics.    This resistance and tension is common where leaders desire to do the right things and managers desire to do things right.

The root of the problem is that business managers are very tactical and focused on keeping “the wheels on the bus.”  They are event-driven and may react quickly based on the reductionist, cause-effect worldview that most business people comprehend.   What is surprising to me is that business managers tend to treat negative events as something that just happened, and were completely out of their control.   This in fact in many cases is just not true.    Many so called black swan events were actually triggered by siloed and narrow minded thinking of a few individuals, without regard to the whole.   This has lead to a series of small negative events which occur in a narrow window of time, which serves as fuel for a sudden catastrophe.  Often, when looking back, one may have be able to stop or dampen one of the negative events, if they saw the larger picture.  They may have been able to absorb some small pain as a trade off.   A catastrophe is avoided but there will be someone has to be held accountable.   Obviously, no business manager of a particular business function unit will say, “I am going to take one for the team for the greater good of the enterprise.”      

Most business managers feel that they have the right mental model for running their business, within their context.    They often can say:  "everything is great!  My scorecard is green this quarter, and the numbers are trending up, so why do I should I listen to you?  You  <insert personal derogatory insult here>."    Well unfortunately I have heard that logic before, then when things suddenly go red, the blame game starts.   What is surprising, many holistic systems thinkers were able to foresee the consequences of black swan events before they occur.    In many cases when the black swan event does occur, there is either an over or under reaction both either by tactical tool fixes or throwing by up their hands and saying “Sh*t happens!” or my personal recent favorite “It is what it is.”    Perhaps there is no such thing as side effects, just effects?    Admittedly there is a paradox.  A complex dynamical system is difficult to predict by its very nature, but perhaps they can be more deterministic if one has a more holistic view and a better understanding of the system and its behavior over time.    

Systems modeling is a technique that can make a system more deterministic.    There has been a lot of talk about models recently by very well-respected practitioners of Enterprise Architecture including Nick Malik, Tom Graves, and Richard Veryard in the #entarch Twitterverse and Blogosphere.   There is general consensus that there are good models and bad models.   All models are imitations of the real thing, therefore as with anything it has limits.   What makes a model useful is the level of approximation on how it reflects reality and how it is communicated.    The mapping of equivalence classes between structural elements (information) and the mapping of functional transitions between behavior elements (algorithmic/computational) must result in useful homomorphism.    Homomorphism is required to map the space of the real world and the space of the model world in way that can be communicated.  The language and grammar that I am using for this blog is in my native tongue English.   You can judge whether these words are useful or not to your reality, and if you understand English; all the better.    If you do not understand English, then this blog is not useful for you.   But perhaps if I translated it into a different language or grammar, it would be more useful to a different audience.    Articulation of language and grammar are critical to model usefulness. 

Models obviously will never have perfect fidelity to the real thing, but they do attempt to establish some boundaries on what structural variables and behavioral algorithms are exogenous versus endogenous to the system.    This is not always easy to do.   Some factors that are exogenous often influence the system, even though the system has no control over that variable or algorithm.   One can make an argument that almost nothing is exogenous.  Although it is very useful to determine eliminate extraneous variable.      Endogenous variables may also produce their own phenomenon which can produce feedback, both positive and negative from within the system.     Often model boundaries (or frameworks) can get us into trouble as they artificially limit thinking, or as I recently read “places invisible fences in the mind.”   Unfortunately our brains have been trained to see cause and effect in relation to space time.   The challenge is sometimes it is very hard to wrap our minds around things that we cannot correlate and infer.    Cause and effect can be difficult to see within the narrow window of space time in which we view the world.    System dynamics teaches us to expand the boundaries of our mental models and broaden the horizon of space and time.   This can allow for us to see patterns of behavior and phenomenon that are created by in many cases simple structures and feedback.   For those of you who are interested in this, I would recommend Binging “cellular automata” and “The Game of Life” simulation for examples to see how a system can evolve with simple rules in ways that surprise us. 

This brings me to the next topic of simulation.     Simulation is a very powerful tool for enterprise architects to help communicate and reach business managers to help them foresee the consequences of action or inaction before a new solution or policy gets implemented.     It is also useful when it is difficult to articulate a complex problem, and why action is necessary.     As mentioned earlier, it is next to impossible to comprehend and mentally derive conclusions on systems that exhibit complex, dynamic, non-linear behavior.     Even very simple simulations can validate or invalidate models based on how they approximate the real world or produce surprises.   The beauty of using computation and information with simulation is that you can expand time in interesting ways.   Situation tools all for us to “guide thought” and “provide reasoning” on how the feedback of soft variables influences the system in question.    Feedback is essential to learning and experimentation.   Simulation allows for the model to evolve over time more rapidly, especially when experimentation in the real world is slow, too risky, and not cost effective.    It allows for us to examine the world in which is highly interconnected whose dynamics are growing.   

If enterprise architecture wishes to fulfill its promise of delivering value-oriented business outcomes, a different approach to how we use models and frameworks is needed.   Models and frameworks fail when we DO NOT ask the right questions on the suitability to purpose or we eliminate variables that we feel are irrelevant, or we do not have the data.  We as enterprise architects often use models to prove that we are CORRECT or to generate acceptance and build consensus with various business constituencies.    This is not a path to success.    What does work is when models are shared and co-developed with your clients.   Your constituencies will discover flaws, inject their own mental and formal models, and will work with you to improve them.  Perhaps via simulation as mentioned above.   Shortcomings in models are good things, they provide more opportunity to learn and improve model fidelity which increases chances for successful and beneficial outcomes for the clients we are paid to serve.

When we work together with business leaders, we as enterprise architects are better equipped to understand business phenomenon and how the dynamic and complex nature of people, processes, and technologies actually can be harnessed and embraced rather than viewed as something to manage, govern, and control.   Our business clients want to better understand their process flow and information.   They need our help, to help maximize value.   Obviously the nature of dynamical systems are complex and very difficult to predict, and yet the business has a desire for resiliency.  Co-engagement with your clients will allow for balanced conversation around agile delivery of improved business capability with modern technology functionality and predictable operational discipline.

We as a profession have to look forward and think on how we evolve our existing frameworks and models beyond what we use them for today.  We must strive to make our thinking visible, so that it is accessible to a wider array of people, not just other architects.  It is time for us enterprise architects to get out of our boxes in our cushy offices and work alongside with our clients.  To open our minds and discover how they prefer to work and conduct business.    This mindset has completely changed my perspective and outlook on how I approach my beloved craft of enterprise architecture.   

If you have thoughts on systems thinking and modeling enterprises for a complex world, I would love to hear from you.

Did a human did something strange that set a series of events in motion that jeopardized the integrity of the market?   Or what it was a technological problem that created the condition that was termed “information asymmetry” in which traders did not have equal access to information, or the information was delayed, or the information quality was not consistent for all parties.    I will be reading a lot more on this notion as there have been studies on systems dynamics on principal-agent problems in the market place.   

There are numerous questions that require some answers to understand what occurred.   One aspect I feel that has not been acknowledged in the press was although there was failure, the shutdown and startup was very orderly based on how the market behaved before and after.   From an outsider point of view, it appears that a potential catastrophe was avoided because someone interceded before things reached a chaotic state.

Robert Greifeld, CEO of the Nasdaq OMX group, said on Bloomberg TV:

 “We have to make sure no matter what happens the system stays up and the system has a resiliency and a robustness that we did not exhibit yesterday.”

I can only ascertain that Greifeld is strictly referring to the “technological system” but as a whole, I have to say the entire system that included the people, process, and procedures did function well.  Now that does not mean the failure was acceptable, as I am sure there will  some financial and legal repercussions that may not be completely known yet.    But again, the markets appeared to have shrugged it off after the event.

Now what about the technological system?    First and foremost, the environment in which they operate in (the marketplace) has a very large number of actors, variables, conditions, and components.   The whole notion of the market is an incredibly complex phenomenon.   Even so-called experts are befuddled that try to predict the market.   The most successful traders are the ones that accept that markets as chaotic and dynamic and are smart enough take advantage of entropic nature of the market.  They operate in the world of “deterministic chaos” in which there is a degree of entropy.   

The technology elements that support the market exchanges have an equally large number of incredibly diverse elements and highly interconnected.   Over the years the technologies that support markets and exchanges have become very complicated, that has grown by bolting on new functionality that requires integration with older platforms.  Put a complex system with an overly complicated system, well you can guess what may occur.    With that acknowledged, the technological system must not be fragile, it must be antifragile.

In pervious blogs, I mentioned there are four systems that comprise an enterprise suprasystem:  the sociosystem, the techosystem, the biosystem, the econosystem.    

The “actors” in sociosystem acted orderly which fortunately did not affect the overall econosystem or “marketplace”.   The biosystem (how and when reaction of the event) actually worked well from the sociosystem side, but not some much from the technosystem side.   Therefore the technology system failed and was certainly fragile. 

The technosystem within these markets provide one OUTPUT that is valuable ….. that is INFORMATION.

Fair and equal access to information is the lubricant to a healthy market.   One has to wonder if the CTO or Enterprise Architects within these exchanges have the ability to even re-architect something that is has become so complicated and has grown organically where it now beyond compression.    When something is beyond understanding, then the technology drifts into the world of overcomplicated.   Which is some cases will be fine for a while, as long as you can predict the outcomes most of the time and handle events gracefully when you there is a result that falls outside of the prediction range.  (Which will eventually happen.)   Over time these systems will start to erode and decay, they will be more complicated and then move to the complex domain, when the outcomes become erratic and impossible to predict.  You have moved from deterministic chaos to chaos that is not probabilistic.

I believe I can assert that building a complicated technology environment to address a market that is complex by its very nature will lead to more events in the future, perhaps with more grave results than what we have witnessed this past week.    This event should be a wakeup call for all in the enterprise and IT architecture professions to strongly reconsider how we design systems in this new age.

We cannot just say, well I followed this framework and my architecture is perfect. So my architecture is fine.    We cannot point at the implementation and say it was the implementers fault.    We architects must have skin in the game.   Our challenge is that architecture of soft systems are not as predictable as we would like, especially for those of us who come from the world of engineering where prediction is vital.   We need to architect and design systems that operate in a band of tolerated outcomes, as the structures within the system can govern, provide, or guide the right behaviors.    

An architect fails in their job when they design and implement systems that are fragile.    I think an architect gets an average score if the system is robust or resilient.   An excellent architecture is antifragile, that promote right behaviors by smart governance an elegant design.    

As always I am interested in your thoughts…..

The architecture field is moving to more of an interdisciplinary art and science.    Also many architects, myself included, have been trained on producing goal oriented systems.  This teleological approach based on the future state design, based on the current state of the enterprise/organization and the environment in which it lives.   This notion of the as-is state and to-be state has been a cornerstone of architectural frameworks ever since I can remember.      But this notion of the future state has been a very allusive goal.  Often we never get there, as the environment changes too quickly to have a clear picture on what the future state is.

I am encouraged that many enterprise architects are beginning to reach enlightenment on the concepts of complexity.    Systems theory and cybernetics started in in the 1940s and 1950s.   Melanie Mitchell, a professor and researcher on Complexity Science and author of Complexity:  A Guided Tour, from her course Introduction to Complexity introduced me to two quotes from Warren Weaver from his work Science and Complexity (1947).

Translate these problems to our world of enterprise architecture, and one will discover that the enterprise is an self-organized complex system.    Again, as mentioned before in previous blog entries complex and complicated are not the same.  See diagram below. 

(Yes I know this is different from the Cynefin framework, and if you want to know why I drew it this way, that will come in another post.)

So how can enterprise architecture deal with organized complexity?   Perhaps we need think about the architecture of architecture itself or meta-architecture.   Back to some basics:

• Architecture:  is both the process and product of planning, design, and construction of a system.
• System:  A whole compounded of several elements (structures, behaviors, and their interactions) that exists in an environment.
• Enterprise:   A system that has a purpose or mission.

The purpose varies, but an organization’s prime directive if you will, are close to one of the following or in some cases both:

• A private sector firm produces products and services in order to generate wealth for shareholders.
• A public sector organization delivers services which create an environment for constituency prosperity.  

Philosophically speaking the enterprise is a self-creating holon and expresses a fundamental dialectic among structure, mechanism (process), and function (outcome).  

• Function refers forward from the object or process along some chain of causation to outcome.
• Mechanism of object of process looks backwards along some chain of causation explaining how the outcome occurred.
• Outcomes can be planned can be consequential or inconsequential.    Outcomes may or may contribute to the desired goal, some outcomes may be related to the emergent phenomena arising as a side effect of the system. 

The purpose drives an orientation towards a particular goal which again are teleological, there is final state in the system.   Goals are assumed to be static or fixated on a point in time.  Yet the system also exhibits other outcomes that are related to the emergent phenomena arising as a side effect of the system itself.  Some of these side effects can be destructive or transform the entities and their relationships.    This arises as a consequence of the system that may require a level of governance.   It is an autopoietic and adaptive system.  

Autopoiesis literally means "self-creation" and expresses a fundamental dialectic among structure, mechanism and function. An autopoietic machine is a machine organized (defined as a unity) as a network of processes of production (transformation and destruction) of components which:

• Through their interactions and transformations continuously regenerate and realize the network of processes (relations) that produced them.
• Constitute it (the machine) as a concrete unity in space in which they (the components) exist by specifying the topological domain of its realization as such a network. [network in a generic sense].  (Sources: Wikipedia)

Okay, I know this stuff is out there… but please indulge me for a little longer.   Let’s quickly review:

• The enterprise is self-organizing.
• The enterprise is autopoietic as it is self-creating and transforming.
• The enterprise has emergent qualities.
• The enterprise is a dynamic system.

How does one describe something that has these characteristics?    How does one design a system or anything for that matter that is in a constant state of drift and based on the demands placed on the system from both internal and external interactions? 

Unfortunately most of the enterprise architecture frameworks that communicate the architectural processes and end-product are severely lacking with this respect.   Do not get me wrong, I am fan of frameworks to a point, but I fear that they are becoming stifling.   I have witnessed far too many times where they do not drive value or an architect becomes too reliant on them for the ultimate answer.   They are in fact today, too teleological, and we need to think further about iterative experiential architectures instead of the monolithic beast that enterprise architecture is best known for.

Some suggestions for the product of architecture:

• Divide up the enterprise ecosystem into smaller subsystems that may have different viewpoints, views, and models for describing purpose, means, results, and benefits.
• Purpose oriented techniques are focused on the motivations of people and groups of the enterprise sociosystem.  (Perspectives of Constituencies)
• Means oriented techniques (which we are most familiar with) are focused on the composition of structures, behaviors, and their interactions of the technosystem.   (Layers of Fabrics)
• Results oriented models are focused on the realization of the biosystem which address the lifecycle of elements including implementation, transition, and operation within the enterprise.  (Iteration of Stages)
• Benefit oriented models which are focused on the transformation with respect to econosystem or prosper-system.  (Measures of Performance)

 Some suggestions for the process of architecture:

• Bring systems thinking to the forefront of process of architecture were the product of architecture can be partitioned in a way where small scopes of work can be iteratively achieved, and integrated into the greater architecture.
• Enterprise Architecture is a technique and process which does not always include the scope of the entire organization, and can target any business function (IT or others.)
• Combine the notion of agile (spiral) and formal (waterfall) methods to balance freedom/speed/tinkering/innovation and governance/risk/adherence/compliance.

It is my hope that I will find some of you out there that are like minded in this endeavor and are interested in collaborating on these concepts further.   

As always I am interested in your thoughts.

• We have a huge challenge in language and grammar in describing the architecture of the enterprise system.
• We all seem to believe that one two-dimensional expression may not be fully sufficient in describing enterprise architecture of a complex system.
• There are two classes of architects.   There are hedgehogs and foxes.    The hedgehogs stick to their credentials, methods and frameworks.   The foxes are comfortable darting around from one technique.  (Check out the LinkedIn groups on Enterprise Architecture and this will be painfully obvious.)

In an attempt to spark some discussion, I presented the following presentation at the conference.   After the presentation two distinguished colleagues pointed out to me, who I respect greatly, indicated to me that my thinking is a bit ahead of the curve.   I take that as complement in some ways, but in other ways I take it as a challenge.   There was clearly an agreement that framework on its own will clearly not make an architect successful.    Our enterprise architecture frameworks appear to stifle thinking in solving a problem.   Just examining how to link two frameworks together is not easy.  For example, take TOGAF and ArchiMate and although the have similar language their intent in addressing a problem may not be the same.

In my early days as a practicing architect the only architectural layers I thought of was contextual, conceptual, logical, and physical.   A variation of Krutchen's well known "4+1 model" perhaps.    I struggled with these being labeled as “architectural” layers, because, I thought of them as vertical walls that were based on time on where one was in the development lifecycle.   But was it?   Can you use some science to determine what layer you were in?   So that was one dimension, but something was missing.  Then John Zachman introduced us to the Zachman Framework which took these traditional layers and added another dimension on the nature of questioning and inquiry using the classic six interrogatives.   Alas, we had a 6x6 matrix of 36 cells that had an all compassing view of the enterprise.  

I credit Mr. Zachman a great deal for generating his framework using classic engineering and hard manufacturing methods of reductionism.   I personally found the framework of thinking restrictive and limiting, and difficult to comprehend as architects debated on what was which cell we were working on at any given moment.  In addition it had its roots in the development of a HARD system, one that is perhaps fragile because it is static and rigid.   SOFT systems are more complex, they are dynamic.  John Zachman is one of the best architecture and engineering minds of our time as he thought of the enterprise as something that you transacted with, but the thinking around  enterprise and technology has reach a level of enlightenment:   it is an experience which evolves through emergence.  Can you imagine flying an airplane when the passengers are all interacting and reshaping the plane itself?   As an engineer I understand reductionism, but there is more to a system than its parts.     As one of my colleagues said to me, can you understand the ocean by just examining at all the drops of water individually?  (Thanks Kumaran Anandan)

So I looked to examples of art to figure out a way how to express multiple problem domains in a two dimensional format.    The concept of viewpoints was an interesting one to me, but there was a tendency of architects to create too many viewpoints to describe the system in question.   There were process viewpoints, data viewpoints, enterprise viewpoints, system viewpoints, security viewpoints, operational viewpoints, logical viewpoints… but then what was a viewpoint versus a view, etc.    Then enterprise architects wrestled with the enterprise architecture domains….. is each domain a viewpoint, or is it a separate architecture?   These endless debates around grammar and language became mind-numbing. There was too little effort by Enterprise Architects dedicated to solving the enterprise "mess" and wicked problems, as most of the effort was around the language and grammar of expressing the problem and is associated solution.    So I began to research philosophy, then system theory, then complexity theory, and now set theory to better understand and describe how to think about complex or “wicked” problems.   

Systems thinking is around the concept of describing mental models.   Mental models at least for me, are never two dimensions in my mind.   Modeling a complex system is not easy when one is limited to a two dimensional piece of paper.  As we develop mental models, we think in multiple dimensions. 

Peter Checkland, a thought leader and pioneer in soft systems methods, brought the Soft Systems Methodology (SSM) and the PQR formula.  Simply stated:  Do P by Q by achieving R.   The links between P-Q, Q-R, and R back to P become worthy of exploring.   (For more on PQR and SSM, see previous blog entries).

 Again credit to Zachman for introducing us to the notion of knowing the type of question you are answering.  Putting the best of hard and soft system thinking together, it lead me to create this mental representation below.    When examining a system, its subsystem, or its elements, there were always four dimensions to consider at any given moment.   

Then l added the ISO 42010 (formerly IEEE 1471) concepts of viewpoints, describing motivation, composition, realization, and conglomeration.   (Yes I do not like that last word either, I am working on it.)  Each of these viewpoints have different considerations that one has to think of, but there are also interconnected by different aspects.

Each of these viewpoints carry with its own way from moving from course to finer grained descriptions of the system.    

 I am not suggesting or implying any framework or indicating that one has to use all or any of the views that I have described above, as well all need to develop our own fit for purpose views based on the system in question they are trying to address.    What is encouraging is that there is momentum in many of the more modern architecture frameworks that aligns closely (although by no mean perfect) with this representation.   

(Note:  Some of you may be asking why am I doing this.  I have worked with many large organizations both in the public and private sector as an architecture consultant and I typically have to align outcome oriented techniques, in which consultants hopefully are compensated by, with existing frameworks.  Another topic for a blog.)

 The following table is a guide that I use when working with my clients:

 Note:  Zachmans interrogatives do not align to the interrogatives to what I am suggesting.  

I know there is paradox that some of you may be thinking.   And asking:  “Hey you are introducing a framework right?”  My answer to that is perhaps, but it is framework for thinking about complex systems, not about the specification of the system itself.    As one of my colleagues suggested, perhaps a metaframework for architectural thinking?   Again perhaps….   It is my hope that we can bring a level of understanding to enterprise architecture in order to make it more consumable not only for fellow architects, but constituencies outside of our profession.    As I understand this looks complicated, and perhaps it can further simplified.   I will continue to publish these thoughts and as always I welcome your feedback.  

Happy architecting…

The result has been to plan, design, build, implement, deploy, and operate these complicated silo-ed solutions that deliver a set of functionality that may or may not be aligned to business capabilities.   How often do we understand how our solutions directly effect the throughput of our own organizations products and services?    As we enter the modern computing age of big data, cloud, business analytics, consumerization, disruptive technology, volitale marketplaces, etc;  information is becoming the new currency on how the enterprise conducts its business.   The reality is that there is a significant amount of “value” of information that largely remains untapped and underutilized the enterprise.   Alas, the opportunity for modern enterprise architect!

This siloed approach has brought with it a rigid solution that cannot be easily adapted to changing processes or whose information cannot be easily integrated with other systems.   There is a good chance that it was architected perfectly, but perhaps the value of the solution was transient or minimal because no one could figure out how to leverage it to its maximum potential.

As I just finished the book Antifragile by Nassim Nicolas Taleb.   What he characterizes as “antifragile” is that category of systems that not only gain from chaos and entropy but require it in order to survive and flourish.   This has again reaffirmed by belief that these siloed solutions that enterprise architects and other IT domain architects have built over the last 10 years are very “fragile.”   They do not thrive in an environment that has entropy or stress.   They are designed to minimize “agents” that will be stressors to the system.  The end result is a solution/system that is temporarily “fit for purpose" where the end users are treated like a transactional component of the solution rather than an entity that actually engages the users of the solution in meaningful ways.    So how can we think approach the topic of building an “antifragile” enterprise?   First we have to accept Mr. Taleb's assertion that this notion goes beyond building as system for resiliency.    The system has to be built to accept micro amounts of stress or entropy in order to thrive.   This is akin to how systems in nature thrive.   Therefore stress should be treated as a positive event, not one that an architect should shy away from.   But there is a second aspect of this stress.   There has to be amount of observation and feedback into the system/solution in order to “comprehend” the stress.  The capture of these events allows for the modern enterprise to incorporate the experience into the collective knowledge or the “muscle memory” or the organization.   The learning organization comes directly from the practice of systems thinking.  Therefore, I am making my own assertion that building an “antifragile” enterprise is one that knows how to exploit information effectively through the application of modern technology.

One of the beautiful aspects of nature and complex systems is the notion of a loosely coupled-layered architecture.   Layering provides autonomy of certain “processes” or “activities” than can conducted with a degree of isolation from other layers.   Each layer can tolerate an amount of entropy or micro-stresses.   I have referred to these layers in previous blog entries as fabrics.  These fabrics have elasticity and have highly interconnected nodes.    By layering these fabrics, one can build more “rich” experiences, especially for those who are consuming those fabrics at the very top.    This builds antifragility.  

So for the moment permit me to focus the business layer and how information is critical to this fabric.  In order to design and model the enterprise effectively, the enterprise architect has to understand the set of “operations” that can be against information.   How is information acquired, manipulated, disseminated, reported, acted upon, stored, etc.   The information flow within the enterprise is aligned directly to business process.   Information is the lubricant to business processes.  If information is available and can be readily exploited by the “actor” that is associated with that process, then the execution of the process can be done with speed, better accuracy, and the right impact.    So the question that naturally comes to mind for the enterprise architect how to align business capability to solution functionality.     Whether your business is IT, or your business is to support other core business functions is irrelevant, each business function within an organization provides a set of capabilities to support a consumable product or service either for consumption by an external or internal entity.   So another assertion here is that, one has to understand HOW INFORMATION is consumed, rather than obsessing on how INFORMATION is provided.    By examining the lifecycle of information, and treating as valued asset can bring with it the desired effects of innovation, aligned products to marketplace, quality of service, and a more happy workforce.

I do not want to paint this as something that is easy to accomplish.   It is not….we has enterprise architects live in a world where most organizations have the design paradox of complicated bureaucratic governance structure while balancing the diverse set of functionality required to conduct business.    These are competing forces which requires management leadership to understand this tension on how to balance centralized control yet give freedom and autonomy to the actors of the business.  Culture is a huge part of this.  (That perhaps is for another blog.)    In the meantime I hope that we as enterprise architects can be more advocates on the study of the enterprise as an antifragile complex system.   I do believe this requires us to apply the modern architecture style where form follows function, and bring organizational harmony by balancing governance and improving capability though the use of information.  

As always I am interested in your thoughts.   Happy architecting…

Here at Microsoft, we are undergoing a huge wave of technology changes ourselves.  We are dogfooding the next generation of products and using them in everyday activities; both within the confines of work and our daily lives.   Our collective experience has provided us some compelling insights as we are company that has a foot in both the enterprise and consumer space and have witnessed it effects people’s livelihood.    We are also releasing a huge wave of products in the coming months which I firmly believe will unlock amazing potential for our customers.   This subtle shift of orientation from being a great software provider to providing great consumer oriented experiences has dramatically changed the way I work, the manner of how I consult, and the guidance I provide Microsoft clients. 

The old days of IT in which the mindset of “build it and they will come” are gone.  Being a great technology provider does not meet the high bar of our collective customer's expectations today.  Customers want to be included in the enterprise experience and part of healthy technology ecosystem that improves the quality of their lives, both at work and at home.   The IT function must start developing consumer oriented IT services, and enterprise architecture must be front in center of this transformation.  To move towards a more consumption centric model, one has to understand how the business and individuals generate wealth or improve prosperity.  This requires insight on business process and interactions and how they contribute to the organization’s products and services.    Next, process and interactions require data, information, knowledge, and wisdom.      Business architecture focuses on execution.  Information architecture focuses on how information is consumed by the business to make decisions, document transactions or state, and collect knowledge for future consumption.   Lastly, what are the applications and infrastructure required to produce this experience and be agile enough to accommodate the dynamics of an uncertain world in which we live?  The old adage of "putting yourself in the customer shoes" still holds true. 

Applying enterprise architecture to this, a consumer centric experience must lead with the business and its individuals.   The purpose of the business (strategy and motivation), the means of the business (architecture and composition of business), and how results achieved (execution and realization).  The diagram below depicts the relationships.  The orange boxes the business behaviors or the verbs (the HOW) of the business.  The blue and green boxes are business structures or the nouns (the WHAT) of the business; the subjects and objects respectively.   [For those of you who are familiar with ArchiMate the terms and colors shown here are intentional.]  This is what I refer to as a business sentence.  The aggregation of these sentences define a capability, or does the business have the ability to carry out what the sentence describes.    The blue boxes at the center (the subjects) is where people and their roles fit in.   They, the subjects, are at the center because they execute the verbs with data/information (or objects).     Bad data, bad execution.   Bad execution, bad processes.     

So how does this shift change technology?   This requires a different orientation moving away from vertical and siloed solutions into horizontal or fabric oriented solutions where technology components are loosely coupled and be managed autonomously.  (See previous blog entry).     Technology that is used to promote business productivity around collaboration and communications has to be highly available everywhere and on any device, period.  The device may be desktop, laptop, tablet, phone, or sensor.   Consequently, data has to be surfaced in compelling ways where it can be acted upon.   In some cases it will be analysis in real time, and in other cases it data will be mined to run what if scenarios and provide inputs to business simulations to help test business strategies.   Here is where business productivity and business insights come together, or what we refer to as the collaboration and big data workloads.

People are the ultimate consumers of processes and information.  By having this mindset when designing an effective and efficient enterprise, I found that I have satisfied my clients by improving their own, their employees and their customer experience.   This results in more prosperity for their constituencies and revenue for their business.   A win-win.  

Enterprise architecture is the profession, discipline, and technique which brings this all together in meaningful ways that drive business results.    So before we all debate the frameworks, the protocols, the technology, the platform.... take a step back and ask yourself if the conversation you are having is driving value with your customers or constituencies.     If not, perhaps the debate is not worth having.    Are you on the same journey?    As always, I am interested in hearing about your experiences. 

I was shocked when I had heard this, and images of ostriches with their heads in the sand immediately came into mind. I was new to my career, and attempting to challenge the old masters of the all mighty Information Systems department was considered blaspheme. After that I was labeled a heretic and could not persue any sort of transformation that would modernize technology or for that matter the business. Over the years the answers were always the same:

• “That will not meet our requirements.”
• “This goes against our security policy.”
• “We do not support that {tool, technology, process}.”
• “If it ain't broke, why mess with it.”

These statements have been picking up recently from a variety of information technology professionals, and sadly from enterprise architects. To be frank, I fear that many IT departments or IT related businesses are at risk of losing relevance.  The world is changing faster than ever, yet there is still this strange clinging to the old ways. The truth is that the Internet has changed business forever, but I believe the potential remains largely unexploited. Enterprise architect professionals cannot meet the demands of the next century if there is no strategy to address business transformation, device consumerization, cloud computing, mobility, and exploitation of data.

So why is IT stuck? The answer came to me while listening to a great presentation at Microsoft’s semi-annual Architecture Summit for employees.  Norm Judah our Worldwide Chief Technology Officer for Microsoft Services delivered a compelling presentation on the topic of need versus desire. Over the years many of the roadblocks that were thrown up by IT were based on a personal desire of IT professionals and not on the actual needs of the business. This interesting duality also has forced me to think about truths versus beliefs. I thought of needs as being truths, where evidence was provided in support of the need or requirement. Desire was actually something more personal, having an emotional component that addressed a level of desired functionality.

Many years back, I was working on a large directory implementation that required domain naming services (DNS) in order to function.  There was a “desired” functionality (or belief) from the DNS administrators to have the system by managed in a particular way which resulted in a structurally more complicated DNS namespace.  As a result, a simple foundational DNS service had more structural elements which in turn made any solution that leveraged it even more complicated and difficult to exploit.  I remember pushing my client at the time very hard on this, to examine what were the true “needs” of the DNS administrator.  What was the true business need? Where was the evidence? I never got the “truths” I was looking for as I was clearly sticking a knife in someone for just asking the question. As a result, this client is stuck with a very structurally complicated solution that has limited behavioral flexibility.  It satisfies the desired functionality of the IT provider but not for the consumer.  The cost of the solution is now more expensive to operate, and the cost of lost opportunities because the lack of flexibility is astoundingly more.

This presents us a very interesting physiological exercise on the needs and desires of the self. Carl Jung made the following observation on the topic of Neurosis: “I have frequently seen people become neurotic when they content themselves with inadequate or wrong answers to the questions of life.”

If I may take this one step further: “I have frequently seen IT professionals become neurotic when they content themselves with inadequate or wrong answers to the questions of the business.” I have heard the following statements all within the last six months.

• “We will never use the cloud because of security.”
• “We are required to use {insert protocol here} because of our strict enterprise architecture governance.”
• “Yes we have monolithic system, but we do not have time to architect changes it so we just keep adding and re-engineering it.”
• “We do not need to talk to the business, I have been here 20 years and I know what they need.”  (uhhhh, seriously?)

Of course there are real “needs” that are requirements and constraints that are well defined that relate to business policy, regulatory requirements, human safety, privacy, and security.  They are usually supported by economic data around value, cost, risk, and opportunity.   These are rooted in truth because there is the evidence that they are required. These constraints must be surfaced and any “complicatedness” that is introduced into the solution may be absolutely necessary.  On the other hand, adding elements based on notion that is based on “desired” behavior of the technology provider has to be carefully scrutinized as to not artificially introduce complications.  As a result:  the desire to build something from scratch, the desire to use the coolest new thing, the desire to buy a tool, the desire to be in control, etc.   These all leave behind a cacophony of spaghetti-like of solutions with a small number of business capabilities actually delivered and large number technology configurations.  Yes you are stuck.

This desire fuels us to build systems that are overly complicated.  I am careful not to use the word complex, as there is confusion on the definitions of complicated versus complex. Complicated systems fall in the realm of known and predictable.  Complex systems are not always known and not always predictable. For example, a modern passenger airplane is very complicated due to the massive number of elements and variables, mostly of which are tightly managed and controlled. The concept of passenger air travel is very complex as many elements and variables are loosely managed and sometimes outside the possibility of control.

As an engineer I hated randomness. I wanted control. Most IT professionals are still in the world of control based on this desire. Is there really a need for control? Or is this just to satisfy a desire? As an architect, I have grown to appreciate the value of a certain amount of entropy in the systems I am involved with as this allows for emergence;  and in turn plants the seeds for business and user innovation.   Therefore I have to be comfortable to give up some aspects of control.   Standards are important to keep complications to a minimum, but at some point, they can be stifling if they are based on the desires of the provider. I cannot tell you how often I have seen an under exploited solution because of what I call over governance.  Therefore I do not mind a certain degree of complexity with respect to the user freedom.   But I vigilantly question the motives of an overzealous IT professional, developer, or manager when a solution gets over-engineered due to desire.

It is my belief that enterprise architecture must propose and help build solutions that are simple, yet can evolve and be fully exploited as business demands change.  This requires and understanding that discriminates needs from desires, truths from beliefs.  This is a conversation that I have with my clients when discussing true business transformation.  Desire comes with a price, and we clearly have to understand the cost and value associated with it.  Most often, but not always, desired functionality coming from outside of IT most likely will generate value; desire from inside most likely will have an associated cost.

My goal as an architect is to generate enough desire for the consumer (business) while balancing the needs of the provider (IT).  Business moves fast, and technology is moving even faster. Managing the mess in the same way we always have will clearly set us up for failure. The definition of insanity according to Albert Einstein was “Doing the same thing over and over again expecting a difficult result.”

The discipline and professionals of enterprise architecture cannot be plagued with this type neurosis.  As architects we need to be advocates of the needs of the providers and the consumer’s desires of information technology.  Additionally, there is a characteristic of enterprise architects that is often lacking today.  The quality of selflessness is one that enterprise architects must come to terms with.  Can you as an architect put the desires of your customer before your own? If we are going to address the opportunities of device ubiquity, big data, hyper mobility, and cloud computing; we must all think differently or lose relevancy like SNA and Token Ring.   May I interest you in taking a transoceanic ride in a steamship?   I thought so.

As always I am interested in your thoughts.

Disclaimer: The opinions and views expressed in this blog are those of the author and do not necessarily state or reflect those of Microsoft Corporation.

The idea had to simmer a bit, but clearly as a profession we need a new set of competencies in order to be the type of Enterprise Architect capable of managing the CIO, and the entire IT function for that matter.

First of all, Enterprise Architects have to manage a profit and loss center and learn how to run a “business.”  Running a business requires understanding of a business.  Even running a small business teaches one basic accounting, sales and pipeline management, disciplined execution, customer service and support.  I think it is fair for me to day that most Enterprise Architects (not all), really do not even understand the nature of their own business.   Business acumen is essential and the development and exploitation of new business models would be essential.

Second,  Enterprise Architects must learn how to manage the most important asset of the firm:  People.  I do not believe I am going out on a limb by saying that most Enterprise Architects today would not be very good people managers.  Having managed people before, I have to say it is very time consuming and distracting!   Architecture, at least for me, requires intense concentration.  I do not like being interrupted when trying to solve a problem as I have my head immersed in it.  Managing people requires that you have to be able to disengage and reengage quickly as your reports tend to do random things.    The discipline of architecture does not lend itself to multitasking.   If you believe you can multitask and develop a high quality architecture in a timely manner, send me a note.

A modern Enterprise Architect must able to apply systems thinking using both analysis and synthesis.  (See previous blog entries.)   Many of us have come through the ranks of engineering and software development which teaches us classical ways of problem solving through reductionism and optimization of elements and parts.  Engineers thrive on being able to predict things.  Moving from an engineer to a designer shifts your thinking more towards synthesis.  Architecture is not pure engineering, but its “truths” are grounded in engineering a reality.   Architecture is not pure design, but the designers “beliefs” have to transform or manage the firm into perhaps uncharted territory or navigate through uncertain environments.

I think for now, I would welcome that the firm’s Chief Enterprise Architect to report directly to the CIO and be the strategic arm of the IT function.   What would be more likely is that the future enterprise architect would report to an up and coming role called the Chief Strategy Officer.   An enterprise architect, or whatever the role is called in the future, would benefit being a part of “The Strategy Office” similar in nature to the “The Project Management Office” but responsible for the design of the firm and determining the means required to satisfy the purpose of the firm.

As always I am interested in your thoughts…

My journey in architecture has brought me to the conclusion that “systems thinking” is the new essential core competency in enterprise architecture.  As one considers a system, there is a process where ones has uncover the essence of the system in order to solve a problem or address an opportunity that is worthy of investment.

Problem Solving 101

My career began as a software developer, and have followed various frameworks that all essentially accomplish a common flow of problem solving with a set of artifacts and deliverables.   This is a list which guides my own activities, in order foe me to produce the right artifacts and create the “desire” to get my clients to adopt the platform or system I am proposing ot building.

1. Motives, Goals and Objectives.  Define purpose, intent, metrics and outcomes.
2. Requirements and Constraints.  Understand stakeholders.
3. Specifications.  Define the change.
4. User Impacts.   Define the impact.
5. Planning.   Define the approach to change and measurement of impact.
6. Schedules.  Define the timing and sequence of activities.
7. Track Success: Measurements.   Track against motives, goals, and objectives.
8. Repeat. 

But there is something more basic to this.  There appears a natural order to this:

1. Why
2. Who
3. What
4. Where
5. How
6. When
7. Measure against Why and Who

I would like to point out that is not exactly equivalent to Zachman’s interrogatives, but he deserves credit that his Enterprise Ontology is aligned with answering interrogatives.  This technique allows me as an architect to provide a complete and holistic picture of the system.

Outcomes, Based on a Collective Point of View

Before we begin to solve the problem, the two first interrogatives start the process.   Who are we going to be working with?  Why do they care?    The intent here is to establish the “purpose” of the system that me or my team is asked to address.   This often includes an assessment of the current system, its elements, and why does it need to change.   We begin by establishing context by understanding internal and external factors which may impact stakeholder’s motivations for the system in question.   Through the processes of establishing purpose, we attempt to get as many diverse perspectives from constituencies that interact directly or indirectly with the system.   Each constituent has their own reality of perception of their desired outcome based on a point of view.   These viewpoints are based on motivations and helps frame the scope of transformation required and desired results.   A holon, in this context, is an individual or a grouping of individuals that addresses the “self” or “collective” concerns and goals based on architectural qualities of motivational aspects including efficiency efficacy, & effectiveness.

Q.E.D.: That is Which to Be Demonstrated

Once the team is comfortable with the purpose, now comes the part where the team that is tasked to construct the “change” has to determine the means of accomplishing the purpose.  What are the elements required; both structural and behavioral and where will they reside where the outcome impact will be observed, measured and tracked.  This is typically where the architectural sweet spot is, the world of abstraction, layers, and decomposition of elements required to define the building blocks of the system.  These often are decomposed or partitioned into subsystems that can operate in a semi-autonomous fashion that provides a level of flexibility.  These viewpoints are related to various layers or subsystems that are integrated into a larger whole These viewpoints are typically based on layering of knowledge oriented domains that address the composition of the system.  The fabric concept is used here to provide the right degree of partitioning and integration between subsystems where elements within the fabric produce or serve the fabric above it, where all the fabrics are integrated by loose coupling mechanisms.

Pushing the Change Out and Measuring Performance

Once the composition of the system is adequately described, the next area of focus is to determine how and when the system will deliver the anticipated outcome and results.  Results should be measured over time to ensure that the system change is introduced with minimal disruption to existing system and performs as specified.   The realization of system is defined by a series of stages including stages of development and operational events.     These viewpoints move the system from an idealized state to a realized state through a series of activities in moving from contextual beliefs and knowledge to physical truths and realities where impacts are measurable.   Performance management of the system also has viewpoints that define correct operation in a change and steady state to improve, maintain, or dampen the impact of change, both positive and negative change.  Each iteration of the system either changes the system in some cases to add more functionality or in other cases an event can cause an iteration of the system to lose functionality. 

The Soft Systems Methodology

This method of problem solving has actually a formal methodology called the Soft Systems Methodology (SSM).  A soft system, such as the enterprise system, is developed where problems sometimes are difficult to quantify due to the randomness, feedback, and dynamics.   Using a soft systems approach is useful for describing various architectural viewpoints around motivations, elements, interactions, and methods which address both quantitative and qualitative dimensions, using analysis and synthesis in tandem.   Peter Checkland, a professor of Systems at Lancaster University, developed SSM using system thinking techniques.   There is a seven stage approach of SSM that aligns roughly with this approach called the PQR.  Understand P by doing Q in order to achieve R.   

 Checkland also advocates use the moniker CATWOE to establish context of a purposeful transformation.  This table belows summarizes:

 With respect to performance criteria, Checkland goes on to state that these three criteria area always relevant.   They are known as the three E’s.  These can serve as a starting point to define some goals around results.

I have added some other E's to consider: 

Evade:  Reduce organizational risk through transformation.

Enact:  Build new capabilities to improve throughput. 

Evolve:   Be more competative through transformation.

A systems thinking approach like SSM can help benefit the Enterprise Architecture discipline of  looking beyond the composition of the“architecture”  itself in order to align with the purpose of transformation and how to measure the performance of the architecture over time.

Here is an example output of how to use the SSM to determine how the Enterprise Architecture can address a supply chain system within the enterprise system. 

Alignment of Architectural Viewpoints and Views

There are many types of architectural viewpoints and one may categorize them based on the types of concerns they address.  The challenge is that when one combines multiple viewpoints, it gets difficult to understand the relationships between other viewpoints.  Applying some physics to the system, the system lives in four dimensional vector space, that consist of space, time, and impact.  Consider that I can represent the enterprise system as super imposing three 2-dimensional planes at right angles to each other. I know this may seem a bit heavy here, but hang in there. 

In the world of understanding the transformation purpose, viewpoints that related to desired impact of the system as it relates to the space of the system that is resides in.   When describes a system’s means of composition, the systems’ structural configuration resides in space and its behavior protocols are executed as it relates to time or order of operation of activities.  The realization of results of a system requires that system be instantiated and be maintained over time, and continuously monitor to ensure that the measured impact either matches or exceeds the desired impact.  Therefore viewpoints that are associated with stages of realization and operation are often used to describe the phases of the system.’

Aligning PQR, with the problem solving interrogatives and types of viewpoints allows us to address the problem two vectors at a time. 

The following table addresses how viewpoints align with various plans and vectors.

Put this all together and you have a fairly comprehensive picture on enterprise transformation and it relationships to viewpoints.

ArchiMate 2.0

The release of ArchiMate 2.0 by the Open Group this month now presents us with aspects to address the entire transformation cycle.   The ArchiMate Framework fits in describing the composition of the enterprise system.   The two new extensions:  Motivation and Implementation and Migration help address Purpose and Results more completely.  Although ArchiMate on its own may not address the entire problem space, it does provide a good foundation that I believe aligns itself quite well with thinking of the enterprise as a system.  The additions to ArchiMate now help enterprise architects to address the mess in a more complete fashion.

What is Next?

I have presented this material at the Open Group conference in San Francisco this month and at Microsoft’s internal TechReady conference and the feedback has been positive so far.   At this point it nowhere near complete and requires some more research and study.   I am currently applying this technique on my current assignment and so far it is working quite well.  I will post more comments and feedback as my systems thinking journey on Enterprise Architecture continues.