entarch

Architect or Coach?

by
Is it just me, or are others finding the Enterprise Architect role shifting towards ‘Coach/Facilitator’? 
These days I find I’m most attracted to Tweets about workshop facilitation and business analysis techniques rather than anything discussing Enterprise Architecture: frameworks, methods and tools. 
Here’s a few links I’d recommend for those interested in the former.

Algorithmic Enterprise Architecture

by

Can some or all ‘design’ decisions we make as Enterprise Architects be automated via collection of datapoints, algorithms and assessment against patterns of architecture?

I read an article the other day in Wired magazine about jobs being consumed by algorithms e.g. Taxi drivers and google self driving cars. It made me think about what I do as an Enterprise Architect and what elements of an ea role could be subsumed by an algorithmic approach. So I thought i’d write a brief post to nail down a few initial thoughts.

Some assumptions:

1) When we engage with stakeholders to understand the baseline architecture we are effectively capturing data points and their relationship to one another.

2) When we map different layers of an architecture we are merely segmenting some datapoints.

3) When we map views of a target architecture and the transitions to it we are taking our understanding of existing datapoints and mashing them against new ones around vision, principle, drivers, goals objectives, constraints

4) Whether they know it or not, all organisations are a collection of (known or yet to be discovered) patterns or anti-patterns. 

Assuming the previous statements are true (big assumption but lets pretend for a minute). What if there was a tool that consumed datapoints of an Enterprise Architecture and datapoints of the vector of the future state and in so doing created simulations and recommendations on the optimal target architectures for the organisation?

Whole-Brained Business Analysis – New Metaphor Required

by

I’ve been guilty using the much debated ‘Left vs Right brain’ metaphor to explain what I believe is needed. By way of example, Alec Sharp (@alecsharp), Sally Bean  (@Cybersal), Roy Grubb  (@roygrubb) and I have been Tweeting about Concept Modeling vs Concept Mapping. Alec is keen to get Data Modelers to abstract their thinking up from physical Data Models by thinking conceptually and I have been encouraging Business Analysts to think similarly when gathering requirements. This has meant that we both find that we need to introduce a different mindset: one that encourages more creative & inclusive discussion atthe initial   discovery and play-back stage of the Requirements-Solution Design journey. I expect the Agile/XP community will declare this to be their philosophy (and nothing new) and they’re probably right. But rather than get caught-up in ‘IT-centric’ methods, I’d rather think of it as a way to better understand any requirements for change – regardless of the Software Development Life-Cycle. I’d rather see such thinking applied to all aspects of business change – people, process, practice, policy and … technology.


Tried-and-tested analytical techniques should not be abandoned, they just need to be augmented with others that, in my experience, help expand ideas and produce resilient, coherent and business-value-creating solutions.  Both side of the equation are equally important. However, I’m finding (through experiment) that the more creative techniques are more engaging – simply more fun and inclusive – and, this alone, can, in my recent experience, dramatically improve business outcomes. 

In attempts to explain the need for a more ‘whole-brained’ approach, I’ve been following the lead of the ‘Design Thinking’ community in referring to both Theory X and Theory Y from MIT Sloan and the Left-brain Right-brain metaphor. This, however, is fraught with problems due, in large part to the findings of the University of Utah who debunk such binary thinking (as I was reminded by Rob England – @theitskeptic).

So I’m in a quandary: on the one hand I find that an X-Y, Left-Right, metaphor is a simple way to convey the difference between, say, Analysis vs. Synthesis, on the other hand, however, I run the risk of aligning with outdated concepts being fundamental reconsidered by neuroscientists. 

I guess the Complexity Science community might say that I’m talking about the difference between ‘Complex Adaptive’  vs. ‘Complicated’ systems, but, again, academic debate makes coming up with a simple metaphor next to impossible.

Has anyone found an alternative metaphor for a more balanced approach to Business Analysis and Enterprise Architecture?

Importantly, I’m keen to avoid the impression that people are to be seen as fundamentally one way or another. My observation is that it is the practice of Business Analysis/Enterprise Architecture that needs to be more ‘Whole-brained’ – not the individuals per se.

To get the discussion rolling, I’d like to hear views on:
  • A good Business Analyst or Enterprise Architecture must be a balance of Left-X(Reliability – Doing-things-Right) and Right-Y (Validity – Doing-the-right-thing)
  • We’ve spent to much time of methods that attempt to industrialise EA (the TOGAF 9.0 manual runs to around 800 pages in the attempt) and BAs are too often focused on methods focus on an ‘IT solution’ rather that the Whys and Whats of the current or desired business behavior
  • We need to spend more time on developing pattern-based storytelling skills in BAs and EAs to deliver break-through changes and allow for innovation in TO-BE models.
  • Economic churn and environmental challenges warrant more Y-minded thinking (with appropriate X-controls)
  • The world can’t be fully explained or governed algorithmically (thank god!)– not while values and trust dominate the way organisations function.


 

Whole-Brained Business Analysis – New Metaphor Required

by
I’ve been guilty using the much debated ‘Left vs Right brain’ metaphor to explain what I believe is needed. By way of example, Alec Sharp (@alecsharp), Sally Bean  (@Cybersal), Roy Grubb  (@roygrubb) and I have been Tweeting about Concept Modeling vs Concept Mapping. Alec is keen to get Data Modelers to abstract their thinking up from physical Data Models by thinking conceptually and I have been encouraging Business Analysts to think similarly when gathering requirements. This has meant that we both find that we need to introduce a different mindset: one that encourages more creative & inclusive discussion atthe initial   discovery and play-back stage of the Requirements-Solution Design journey. I expect the Agile/XP community will declare this to be their philosophy (and nothing new) and they’re probably right. But rather than get caught-up in ‘IT-centric’ methods, I’d rather think of it as a way to better understand any requirements for change – regardless of the Software Development Life-Cycle. I’d rather see such thinking applied to all aspects of business change – people, process, practice, policy and … technology.


Tried-and-tested analytical techniques should not be abandoned, they just need to be augmented with others that, in my experience, help expand ideas and produce resilient, coherent and business-value-creating solutions.  Both side of the equation are equally important. However, I’m finding (through experiment) that the more creative techniques are more engaging – simply more fun and inclusive – and, this alone, can, in my recent experience, dramatically improve business outcomes. 

In attempts to explain the need for a more ‘whole-brained’ approach, I’ve been following the lead of the ‘Design Thinking’ community in referring to both Theory X and Theory Y from MIT Sloan and the Left-brain Right-brain metaphor. This, however, is fraught with problems due, in large part to the findings of the University of Utah who debunk such binary thinking (as I was reminded by Rob England – @theitskeptic).

So I’m in a quandary: on the one hand I find that an X-Y, Left-Right, metaphor is a simple way to convey the difference between, say, Analysis vs. Synthesis, on the other hand, however, I run the risk of aligning with outdated concepts being fundamental reconsidered by neuroscientists. 

I guess the Complexity Science community might say that I’m talking about the difference between ‘Complex Adaptive’  vs. ‘Complicated’ systems, but, again, academic debate makes coming up with a simple metaphor next to impossible.

Has anyone found an alternative metaphor for a more balanced approach to Business Analysis and Enterprise Architecture?

Importantly, I’m keen to avoid the impression that people are to be seen as fundamentally one way or another. My observation is that it is the practice of Business Analysis/Enterprise Architecture that needs to be more ‘Whole-brained’ – not the individuals per se.

To get the discussion rolling, I’d like to hear views on:
  • A good Business Analyst or Enterprise Architecture must be a balance of Left-X(Reliability – Doing-things-Right) and Right-Y (Validity – Doing-the-right-thing)
  • We’ve spent to much time of methods that attempt to industrialise EA (the TOGAF 9.0 manual runs to around 800 pages in the attempt) and BAs are too often focused on methods focus on an ‘IT solution’ rather that the Whys and Whats of the current or desired business behavior
  • We need to spend more time on developing pattern-based storytelling skills in BAs and EAs to deliver break-through changes and allow for innovation in TO-BE models.
  • Economic churn and environmental challenges warrant more Y-minded thinking (with appropriate X-controls)
  • The world can’t be fully explained or governed algorithmically (thank god!)– not while values and trust dominate the way organisations function.


 

Re-purposing the Technical Debt Metaphor

by

Recently, I had cause to re-visit the ‘Technical Debt’ metaphor coined by Ward  Cunningham when referring to agile software development:
I am finding, however, it applies to a much broader set of circumstances such as: unmanaged introduction of Consumer-grade I.T., Line-of-Business ‘Credit -Card-Cloud’ consumption and ‘technology-solution-without-a-requirement-and/or-architecture’ implementations. So I’ve had a go a rewriting Ward’s original words:-

“Technical debt is a metaphor an incremental, get-something-started approach with the easy acquisition of money through fast loans.

A monetary loan, of course, has to be paid back with interest. In terms of software development & technology selection &  deployment, payback requires the technicians to re-work the solution as they learn more about how it interacts with other technologies and which features are being used, or not, or are now needed. Just as monetary debt can easily spiral out of control if not managed properly, so can technical debt.

In business, the metaphor is often used to illustrate the concept that an organization will end up spending more in the future by not having sufficient understanding the complete requirements before selecting a solution. The assumption is that if an organization chooses to ignore a course of action it knows should be taken, the organization will risk paying for it in terms of time, money or damage to the organization’s reputation in the future. As time goes by, efforts to go back and address the missing requirements may become more complicated and, otherwise, messy. Eventually the problem may reach a tipping point and the organization must then decide whether or not to honour its original debt and continue investing time and effort to fix the problem. This decision can be made more difficult by something called ‘the sunk cost effect’, which is the emotional tendency of humans to want to continue investing in something that clearly isn’t working (e.g. can’t scale or missing features)”.


Anything you’d add/change/delete?

Re-purposing the Technical Debt Metaphor

by

Recently, I had cause to re-visit the ‘Technical Debt’ metaphor coined by Ward  Cunningham when referring to agile software development:
I am finding, however, it applies to a much broader set of circumstances such as: unmanaged introduction of Consumer-grade I.T., Line-of-Business ‘Credit -Card-Cloud’ consumption and ‘technology-solution-without-a-requirement-and/or-architecture’ implementations. So I’ve had a go a rewriting Ward’s original words:-

“Technical debt is a metaphor an incremental, get-something-started approach with the easy acquisition of money through fast loans.



A monetary loan, of course, has to be paid back with interest. In terms of software development & technology selection &  deployment, payback requires the technicians to re-work the solution as they learn more about how it interacts with other technologies and which features are being used, or not, or are now needed. Just as monetary debt can easily spiral out of control if not managed properly, so can technical debt.



In business, the metaphor is often used to illustrate the concept that an organization will end up spending more in the future by not having sufficient understanding the complete requirements before selecting a solution. The assumption is that if an organization chooses to ignore a course of action it knows should be taken, the organization will risk paying for it in terms of time, money or damage to the organization’s reputation in the future. As time goes by, efforts to go back and address the missing requirements may become more complicated and, otherwise, messy. Eventually the problem may reach a tipping point and the organization must then decide whether or not to honour its original debt and continue investing time and effort to fix the problem. This decision can be made more difficult by something called ‘the sunk cost effect’, which is the emotional tendency of humans to want to continue investing in something that clearly isn’t working (e.g. can’t scale or missing features)”.


Anything you’d add/change/delete?

#INFOARCH – INFORMATION OWNERSHIP

by

While I am preparing to publish my next article on Information Management and taking the opportunity of a email discussion with Jean Evelette – the author of the very interesting website MARS – Metadata And Repository System – I realized that a clarification regarding information ownership was needed. Here is the famous question: Who is owning the information? I […]

The Most Important EA Deliverable

by

Originally posted on Alec Blair:
So, you’re busy working away at your models.  The team is busy discussing the nitty, gritty things around taxonomies and ontologies.  Others are creating detailed elaborations of different aspects of one of the dimensions of your enterprise architecture.  You look at the work and say, “Damn this is good stuff!”…

Gordian knot, butterfly effect:Organizations are a study in complexity

by

Business is complex.  Gone are the years of simplicity in business operations.  Exponential growth and change in regulations, globalization, distributed operations, changing processes, competitive velocity, business relationships, disruptive technology, legacy technology, and business data encumbers organizations of all sizes. Business … Continue reading →