Aggregated enterprise architecture wisdom
One way of thinking about an operational data store is to be a near real time repository of/for transactional data organized to support an essentially query workload against transactions within their operational life. This is particularly handy when yo…
This is my final post in a long series of posts where I used the great post from Ivo Velitchkov as a red line to explain my thinking. Following posts did I create so far:
So it is time to summarize the whole series and once again I like to use a quote from Ivo:
In summary, more often than not, when contemporary mainstream EA is trying to introduce a common language, it creates confusion and additional work to deal with it. When trying to bridge the silos, it creates new silos instead. When trying reduce the IT spending, it in fact makes no change or increases them. When trying to deal with complexity, it’s just pathetic
I completely share Ivos line of thinking here. The first observation (“When contemporary mainstream EA is trying to introduce a common language, it creates confusion and additional work to deal with it”) is actually the main reason that started my work on GLUE. I was facing a situation where multiple software supplier and various integrators including a fairly diversified internal IT process structure had to deliver towards 4 releases every year without sharing any common knowledge and understanding, but all of them tried to teach introduce their approaches. So, I have to confess, in my first line of thinking, GLUE was just another stupid approach to create a common language to try to bring them all on the same page.
After working some weeks on the concepts I proudly presented it and was astonished that my brightness (GLUE) was not obvious to everyone. What I faced (and most of the feedback I collected over several years afterwards) was (of course) full misunderstanding. Everyone was all in for the idea of aligning to language to a single common one, as long as it is the one already used to protect the own way of thinking (tribe). So I totally failed and out of frustration I parked GLUE for a couple of years. Looking back the main problem was that I was so full of being right that I did not listen to those I wanted to follow my line of thinking.
Since then I have my changed my focus and live more up to the concept of being a ChickenBrain. I changed the focus from GLUE being the ultimate truth which everyone has to obey towards a pure mapping tool to identify GLUE diseases. Whatever approach or framework in an engineering context I face I immediately map it into GLUE to double check my understanding of the framework at hand (and to ask sense making questions if needed).
Frank Furedi argues that human thought and action are being stifled by a regime of uncertainty. The only thing we have to fear is the ‘culture of fear’ itself (April 2007),
| McGregor introduced the distinction between Theory X and Theory Y, referring to different beliefs about the behaviour and motivation of workers, which may be embedded in management practices and organization culture. Ouchi argued that McGregor’s distinction doesn’t work for all cultures, and identified a third theory, Theory Z, which he used to explain the behaviour of most Japanese companies and some Western companies.
Theory X refers to a set of beliefs in which workers are lazy, require constant supervision, and are motivated only by financial rewards and penalties. Theory Y refers to a set of beliefs in which workers can be trusted to pursue the interests of the firm without constant supervision, and respond to a range of motivators. Theory Z refers to a set of beliefs about lifetime commitment between employers and employees. |
If we frame fear in terms of Theory-X, then it becomes fear-and-blame and we can all go tut-tut. But isn’t there also a way of framing fear in terms of Theory-Y, without yoking it to blame? Performing artists may experience some stage-fright prior to producing an outstanding performance, and while excessive stage-fright may be debilitating, some degree of anxiety may be a positive stimulus. Are we to ban all forms of anxiety and uncertainty from the organization, so that everyone can feel cosy and safe?
And what about Theory-Z? If an organization is under existential threat, then the members collectively need to focus all their energy and creativity on restoring the viability of the organization, and it would be perfectly normal for them to be emotionally as well as intellectually engaged in this task. Necessity, as they say, is the mother of invention.
All I’m saying is that there are different types of fear, which may have different effects on organizational behaviour. Fear-and-blame is one particular type of fear, but there are other types.
Many workers rightly feel responsible for their work. In most organizations, employees or contractors are ultimately vulnerable to loss of status or loss of earnings if they fail to perform satisfactorily. A completely fear-free organization would be disengaged from its customers and environment, and therefore ethically problematic.
However, a caring organization may be able to attenuate some of this feeling of vulnerability, and provide some kind of safety net that allows people to take reasonable risks without too much fear of failure. Whereas an uncaring organization either fails to provide proper boundaries, or amplifies the sense of vulnerability by capricious and unjust management practices.
@benhammersley at #RSAwork talks about the future of office work, and identifies some of the ways that organizations make themselves stupid. The irony is that a lot of these mechanisms were supposed to make offices more productive and efficient, and to promote collaboration and creativity. As Ben puts it
“We have optimized being on top of things rather than getting to the bottom of things.”
Let’s start with open plan offices. As Ben tells the story, these were introduced in an ideological attempt (supposedly originating in North California) to flatten the office hierarchy, to remove barriers between people, and to encourage people and technology to work together in perfect harmony. There are various dysfunctional versions of this Californian Ideology – see my post All Chewed Over By Machines (May 2011).
In practice, various interesting forms of behaviour emerge in open plan offices. Ben notes the widespread practice of more powerful workers grabbing the desks near to the wall, leaving juniors huddled in the middle in a state of permanent anxiety, as if they were antelope anticipating the lion’s pounce.
Many offices are designed as semi-open plan, with people huddled in cubicles, but with the constant chance of someone popping a head over the partition.
In some offices, there is a deliberate policy to move people around – sometimes called hot-desking. One of the supposed benefits of this policy is that it encourages workers to constantly develop new relationships with their transient neighbours. For companies whose workers don’t spend all their time in the office, this policy also reduces the amount of office space required. However, the uncertainty and anxiety of getting any desk, let alone a decent desk near the wall and away from the more irritating co-workers, might be regarded as a negative factor.
Putting aside the economics and culture and psychological impact of open plan offices, the essential justification is that they promote communication and collaboration. These elements are necessary but not sufficient for productivity and innovation in a knowledge-based organization. Not sufficient because productivity and innovation also depend on concentrated hard work.
Finally I can see the end of the red line created by the great post from Ivo Velitchkov. So far I have created following posts:
Two more posts to go, this one and another final one. To quote Ivo:
Then of course modelling itself is believed to help in dealing with complexity. But what kind of modelling? A very complicated architecture diagram does not show complexity. It just shows a lot of effort spent in denial of it.
Actually I personally believe that modelling is a great tool and support communication quite a lot, if applied correctly. I also have a couple of models here in my blog which help me to explain and visualize what I think. Looking at them isolated they are most likely confusing and difficult to understand, which makes it sometimes indeed difficult to use them alone. But in the support of the whole storyline, be it as part of a blog post or as part of a presentation the model helps to align the thinking. The one I refer to most here in the blog is actually the circulatory GLUE system:
Coming back to Ivos post there is jokes circulating around me: “When have you last time had a meeting with Kai without him using the whiteboard?” or “We are trained to sit so that we have free view towards the whiteboard.” Scott Ambler has heavily influenced my thinking with his great website about Agile Modeling besides a lot of great colleagues I had over the years who showed skilled approaches in supporting their line of argumentation with the right model at the right moment. I also liked his Whiteboard Warrior concept, but he has put it offline from his website. There is some traces left in the web though.
One of my key approaches is to draw while I speak. Many words (and I say and write a lot) are more often confusing than enlighting, while a single diagram just shows it. Finding those is not always easy, but the more I model the easier it is to create the right drawing at the moment when it is needed. So my advise is: draw to support your line of thinking, explain in pictures, add a story and the whole gets its own life. Which most likely will return back to you one day, grown over time, transformed and morphed, but beautiful. I try to show Enterprise Architecture and the elements which are delivered via Enterprise Architecture in their full beauty, sometimes I fail, sometimes I succeed.
And a model which is beautiful will carry the story way longer and way more emotional than any dry facts. If Dennis Dutton is right with his assumption than it is rooted in human beeings. I found the success in this approach by try and error. Feedback and comments as always more than welcome.
It looks like as if I am getting closer in finishing my exploration of the great post from Ivo Velitchkov. So far I have created following posts:
To quote Ivo once more:
If you are an Enterprise Architect, a popular way to deal with complexity is to arm yourself with a framework. With a good framework, it is believed, you can do two things. First, reduce the variety of the enterprise to just a few things that share the same properties, according to some classification theory and where things doesn’t fit, add more layers of abstraction. And second, reduce the things you can possibly do to just a few but well defined and in a specific order, with well prescribed inputs and outputs, because that was common for so many organisations that did well so that it became a best practice, and the chances are, if you follow this way, it will do you well as well. Now, because of the shared understanding of the beneficial role of the abstract layers, and the boundaryless imagination unconstrained by the reality, there is a serious number of frame-works and on top of them other-works on how to adapt and adopt them.
And once more a lot of truth in it. One of the first things I learned while dealing with complexity actually was that it created panic. Even though it seemed to me quite obvious what the answer is and how to explain it by using an enormous amount of framework knowledge (of course shameless stolen from many) in my explanation I kind of did not really deliver the message. So my current working approach is to remind the audience of one simple short statement of wisdom: “Don’t Panic“.
I like to use frameworks, but the amount of frameworks is indeed enormous and heavily increasing (and I add one by bringing my GLUE thinking into the game). Pragmatic EA has an overview about frameworks which I personally find very interesting (GLUE is not in that list, because I did not register it so far and obviously no one else did).
So I do exactly what Ivo says: “Reduce the variety of the enterprise to just a few things that share the same properties” and it actually helps me to understand the complexity and trace broken information flows. So I personally find it very useful, but GLUE is of course at this very moment nothing else than an attempt to materialize my very own thinking where there was absolutely no need for any agreements with others. So it is strong for me, but most likely useless for everyone else. If you are interested in applying my thinking please let me know, I will see if I can somehow help you in understanding and applying my thoughts.
With respect to Ivos other statement: “And second, reduce the things you can possibly do to just a few but well defined and in a specific order, with well prescribed inputs and outputs, because that was common for so many organisations that did well so that it became a best practice, and the chances are, if you follow this way, it will do you well as well.” I have a different approach. I personally believe that GLUE always happens and is inevitable. So I personally don’t focus as a primary task on implementing one (or many if you look at the amount) framework, but instead I primarily look at broken information flows or GLUE diseases.
And those diseases I then try to fix, sometimes by proposing (and implementing) a framework, sometimes by inventing something new, sometimes by just talking to the people. It all depends on the context, but I try to guide the energy in the system in a way that it allows to emerge an solution.. It is of course very interesting (but not always relevant) to get hung up in discussion about frameworks or become really religious in applying some technique in one or the other way, but try to avoid that discussion, even though it is sometimes needed to cultivate collisions and by that look for something new (if lucky innovative).
Buy-before-build is generally sound advice. But uncritical acceptance and use of this principle has created a cargo-cult mentality.
Gunnar Hellekso has written a great article about the Cult of the Product.
Compulsory reading for every Enterprise Archi…
I continue to explore the red line laid out by the great post from Ivo Velitchkov. So far I have created following posts:drEAmtime – Communication drEAmtime – Bridging the Silo drEAmtime – Capability Cemetery drEAmtime – EPIC SCANd…
Time for post number 6 in exploring the great post from Ivo Velitchkov step-by-step. Here is what I have created so far:
To quote Ivo:
Some attempts to achieve IT rationalisation fail spectacularly. I’m not going to list out the reasons for that. But it is may be sad that such failures discredit EA as a management discipline as whole. But sometimes Enterprise Architect are really able to find ways to discover what’s not needed and how to remove it, or what is underutilised and how to achieve better ROI for it. After all most of them are smart people using good tools. And indeed they shoot inefficiencies and get all the glory and the money to shoot more. But as they rarely get to the cause of the inefficiencies or are in the position to influence the bigger system that produces these inefficiencies, the overall result is an oscillation or even increase in overall IT spending. The increase is because the success of the EA justifies bigger EA budget which is almost without exception a part of the IT budget.
Here Ivo points at one of the most common pitfalls of Enterprise Architecture applied: fighting symptoms instead of the root cause. This has several reasons. First of all external Enterprise Architects coming with a consulting company might not have the needed inside or full pain awareness to truly fight the root cause (some might even look for future business, and a permanent broken information flow is a permanent revenue stream). Internal Enterprise Architects might have a huge reputation problem which quite often is based on Ivos observation. So as mentioned in the other posts a clear focus on fixing the information flow is a good start to shoot at the root cause and get it eliminated or at least plant some seeds to eliminate the root cause later.
But this is clearly not enough. So with respect to fixing the content I apply the WISE SCAN approach, which looks into the future (GLUE Destination):
I share the observation with Ivo that in many cases so called Enterprise Architects do indeed promote decisions which are not following the WISE approach but are focusing to much on some aspects and therefore add to the EPIC complexity. After all the core reason why emergent complexity exists.
The next post will most likely be about the PACE SCAN. Feedback as always more than welcome to help me improve (or get another red line through my own thoughts. Only some posts to go till Ivos input has done its job for me).
I am still not done with exploring the great post from Ivo Velitchkov in which many gems are to be found. My posts so far:drEAmtime – CommunicationdrEAmtime – Bridging the SilodrEAmtime – Capability Cemetery drEAmtime – EPIC SCAN To quote Ivo: But…
In a great post, @JohnQShift explains how to build a culture of learning in your business. He calls this A Matter of Life or Death (Feb 2013)
In the post, John reports one of his clients observing that they had made some progress in their business over the year. By progress, the client meant that
@danlockton is doing a survey How do actual designers use academic literature?What are the barriers you’ve experienced?What service would you like to see?What would be useful to you?Could academics make their work more easily applicable?Here’s my ans…
