This blog entry is a re-post of a posting that I made in the LinkedIn Systems Thinking World discussion group under the Systems Thinking and Enterprise Architecture topic. The context of the dialog was an ongoing discussion concerning the relationship between Enterprise Architecture (EA) and Systems Thinking (ST). Whether EA was a process that dealt with 'hard' or 'soft' systems, and whether such activities were essentially the subject of a 'functional' systems approach. A related blog entry by David Alman describing what is meant by a 'functional' systems approach can be found at systems-thinking-approaches.blogspot.com.au. [Note. David passed away from a battle with cancer on the 18th of July, 2014. If the links fail after a time, that is probably the reason.]
I come from an IT background. I've spent 40 years designing, building, specifying, evaluating and architecting IT systems - mainly in a banking environment. But I've spent time on both sides of the fence, as both the IT developer, and as the agent in the user business environment trying to direct IT support. Melding it with non-IT activities and processes to solve business problems, and working with the planning staff re strategic and operational planning. My expertise is IT, but I established good rapport with the business folks, workers and senior executives, seeing and understanding their problems, desires and needs.
EA, in a lot of the literature and a lot of the practice, is and has been IT folks doing a job, whose main thrust is focused on being able to build and manage the right systems as enablers and expediters for business function. These are complicated efforts which cost big bucks, win or lose. They want to do a good job, but it's tough, especially in a dynamic world with changing requirements. They talk about business architecture as a component of EA, but it tends to be a mechanism to establish context for the IT systems needed to support the business. Function is orchestrated within application architecture and information within data architecture; with function and data being managed as orthogonal entities with complex relationships. Underpinning this is technical architecture, which has its own constantly changing dynamic, driving what can be done, at what cost, at what speed, and how competitive everything is. Within this perspective, I tend to see the line of logic that describes most of this as 'hard' and 'functional.'
As the complexity of the enterprise increases; as attempts are made for greater integration; the EA activity becomes more removed from the functional systems. It evolves to a meta-level. It becomes an activity about people and organizations performing EA about functional systems. Pressures for flexibility, integrity, speed-to-market, data privacy, efficiency, conflicts over data ownership and utilization; items which spread in a network across the entire IT portfolio of a complex corporation. The solutions tend to become more ambiguous and some of the same conflicts that exist in the human part of the organization leak over and rear their head in the architecting of the organization's automation management and planning activities. Including the aspect of EA that involves managing the process of the human stewardship of the complex IT interdependencies which happen at scale. These do not seem to be typical 'hard' problems with systematic approaches to solutions.
There are also IT folks today, similar to the industrial engineers of the 50's and 60's who are trying to reach out past that functional engineering framework and actually use their toolkit and methods to try to be 21st century business people. People where EA is starting to mean 'architecting the enterprise' in the same manner MBA types would look at the task. Focused on business, planning, product, organization, enablement, customer, direction, delivery and control; whether it has a computer involved in the process or not. When they are talking about EA and BA it really is an attempt to talk about the full architecture of the enterprise, what makes the organization tick, what motivates it, what generates success, and why and how does it fail. And how can 'systems analysis' in various forms help in the process. They just happen to have come up through the IT ranks rather than finance, legal, sales or strategic planning. And that's going to influence some of their thinking and techniques. Now, being realistic, somewhere in the architectural design of a 21st century enterprise you're going to be using IT to address some of your needs. Those same functional applications will get designed and built. They are in the mix somewhere. From this perspective though they are a lot more secondary than primary.
An aspect of that thought process about 'architecting,' and the need for ST, is reflected in the language of the June 2012 HBR article by Michael D. Watkins, "How Managers Become Leaders"
As leaders move up to the enterprise level, they become responsible for designing and altering the architecture of their organization—its strategy, structure, processes, and skill bases. To be effective organizational architects, they need to think in terms of systems. They must understand how the key elements of the organization fit together and not naively believe ... that they can alter one element without thinking through the implications for all the others. [Harald learned this the hard way because nothing in his experience as a functional leader had afforded him the opportunity to think about an organization as a system. Nor did he have enough experience with large-scale organizational change to develop those insights from observation.]
... Enterprise leaders need to know the principles of organizational change and change management, including the mechanics of organizational design, business process improvement, and transition management. Yet few rising executives get any formal training in these domains, leaving most of them ill equipped to be the architects of their organizations—or even to be educated consumers of the work of organizational development professionals.
In my view, if you actually try to fully put yourself in the position of the business person managing the business, the IT aspect of "enterprise architecting" becomes just another tool to accomplish tasks within the system (the organization, the enterprise). Sometimes IT is useful. Sometimes it's not. If you want to 'architect' the business, one of the things is to 'architect' the resources. In the 1800's you did that with men and machines. In the late 1900's and the 21st century you do it with men, machines and information systems. But if your focus is to architect the organization, the enterprise, you don't just design the functional delivery part. There are personnel policies, customer strategies, incentive systems, compliance systems, etc. etc. etc. that exist above and beyond the IT systems that might support them. And there's maintenance, direction setting, and conflict resolution between a myriad of human engineered and steered subsystems, and lots of other stuff. Systems of systems of systems of systems. Layered, and orthogonal on a multi-dimensional basis.
If you take EA across the scope of a complex conglomerate, or to the level where you are trying to help the founder/CEO/COO/division-head move through the complete set of life-cycle activities of an organization, help understand it's structure, its control systems, it's mechanics, help it communicate and resolve conflict and help to architect that organization past its next set of critical difficulties; at that level don't you want (need?) to get past that "functional systems" set of tools into more of the full set of ST tools you are talking about in the blog? It is very far from a straight-forward problem at that point.
Now, I don't know if that's where Graham is trying to come from. But I do think there are people coming up out of IT, from the EA space, who are trying to travel both of these paths.
I participated in a business process in the 1980's in the Capital Markets area of Bank of America. The market was very dynamic and expanding. The futures markets were opening up to financial instruments. Swaps were beginning to be traded. The market was turning into a non-stop 24 hour on-line system. It was the cusp of this new financial era. We created a joint team of primarily business people, with some IT support people, and brought in some ex-Boeing consultants to create a new architectural specification for the business. Trading, sales, operations, accounting, compliance. The conceptual and highest level logical architectures made no distinction between what might eventually be done with computers and what might need to be manual activities. We didn't get into human resources as such, beyond compliance issues, because we were dealing with a subdivision of the company and HR was out of scope.
Out of that comes a much better appreciation for where and how and why to apply IT within the organization. But it also brings new techniques and perspectives to bear, potentially, in solving business problems. Maybe, in some cases, you find out it doesn't really make sense to automate (a particular way?) because of some issue. Just like it doesn't always make sense to use heavy-duty farm equipment in third-world environments. Sometimes a shovel is a better tool. ;-)
Given all of this I don't know how the full tool-box of ST maps against the full activity set of EA. I'm still trying to find my way through the forest of ST. But if EA is viewed as an activity set involving the systems engineering of enterprises, ST would seem to have a lot to offer. Which is part of what I thought Graham was trying to drive toward.
Add new comment