design

I Don’t Call Myself An Enterprise Architect

by
… anymore.


A few people have asked why I call myself a Change Designer rather than an Enterprise Architect. The reason is simple: the EA label misrepresents what I do.


The popular understanding of  Enterprise Architect is:
  • attached to an I.T. view of the world – I’m not only focused on I.T.
  • often synonymous with large arcane frameworks like TOGAF – I dislike them
  • regarded as slow, top-down, big modelling up front etc – I prefer Dan Ward’s F.I.R.E. approach.


I use the title Change Designer because:
  • They are two simple words, that together, explain what I do – I Design Change (transformational or otherwise).
  • They don’t t limit me to only focus on I.T. – but, at the same time, they don’t exclude I.T.
  • Much of my thinking and toolset come from the world of “Design Thinking” (and Systems Thinking, Complexity Science etc.).


I guess I’m lucky in the sense I’m unemployable now, partly due to age but mostly due to temperament! 🙂 I’m more choosy about the things I work on where and when. All this means I don’t need to splash “Enterprise Architecture” and TOGAF all over my CV to find the next gig – and if I did, I’d probably not meet the client’s expectations!

Follow #foundindesign on Twitter to see what I’m up to these days.

Found In Design

by

I’ve finally got around to shaping-up the sequel to “Lost In Translation” – the working title is “Found In Design”.I’ve decided to take, what you might call, an “unbook” (as in not a book) approach to this one. I will be writing and sharing early draft…

Pragmatic Application Architecture

by

I saw a tweet on Friday about a SlideShare deck that looked interesting, so I bookmarked it to read later. As I was reading it this morning, I found myself agreeing with the points being made. When I got to the next to the last slide, I found myself (or at least, this blog) listed […]

Designing Communication, Communicating Design

by

We work in a communications industry. We create and maintain systems to move information around in order to get things done. That information moves between people and systems in combinations and configurations too numerous to count. In spite of that, we don’t do that great a job of communicating what should be, for us, extremely […]

Design for Life

by

  The underlying theme of my last post, “Babies, Bathwater, and Software Architects”, was that it’s necessary to understand the role of a software architect in order to understand the need for that role. If our understanding of the role is flawed, not just missing aspects of what the role should be focusing on, but […]

Levels of Architectural Understanding

by

Early on in my EA career, I was very fortunate to become involved in a pioneering EA initiative at Westpac. My introduction to Westpac came when I helped its Group Data Resource Management team develop tool and repository support for its enterprise business model. During this engagement, I kept hearing people refer to an exciting Read more

Levels of Architectural Understanding

by

Early on in my EA career, I was very fortunate to become involved in a pioneering EA initiative at Westpac. My introduction to Westpac came when I helped its Group Data Resource Management team develop tool and repository support for its enterprise business model. During this engagement, I kept hearing people refer to an exciting Read more

Form Follows Function on SPaMCast 403

by

This week’s episode of Tom Cagley’s Software Process and Measurement (SPaMCast) podcast, number 403, features Tom’s essay on Agile practices at scale, Kim Pries on transformations, and a Form Follows Function installment based on my post “NPM, Tay, and the Need for Design”. Although the specific controversies have died down since we recorded the segment, […]

Back to the OODA – Making Design Decisions

by

A few weeks back, in my post “Enterprise Architecture and the Business of IT”, I mentioned that I was finding myself drawn more and more toward Enterprise Architecture (EA) as a discipline, given its impact on my work as a software architect. Rather than a top-down approach, seeking to design an enterprise as a whole, […]

Abstract Dangers – When ‘And’ Meets ‘Or’

by

There’s an old saying that if you put one foot in a bucket of ice and the other in a bucket of boiling water, on average you’re comfortable. Sometimes analyzing information in the aggregate obscures rather than enlightens. A statistician named Francis Anscombe pointed out this same principle in a more visual (though less colorful) […]