By Leonard Fehskens, The Open Group
The enterprise transformation theme of The Open Group’s San Francisco conference reminded me of the common assertion that architecture is about change, and the implication that Enterprise Architecture is thus about enterprise transformation.
We have to be careful that we don’t make change an end in itself. We have to remember that change is a means to the end of getting something we want that is different from what we have. In the enterprise context, that something has been labeled in different ways. One is “alignment”, specifically “business/IT alignment.” Some have concluded that alignment isn’t quite the right idea, and it’s really “integration” we are pursuing. Others have suggested that “coherency” is a better characterization of what we want.
I think all of these are still just means to an end, and that end is fitness for purpose. The pragmatist in me says I don’t really care if all the parts of a system are “aligned” or “integrated” or “coherent”, as long as that system is fit for purpose, i.e., does what it’s supposed to do.
I’m sure some will argue that alignment and integration and coherency ensure that a system is “optimal” or “efficient”, but doing the wrong thing optimally or efficiently isn’t what we want systems to do. It’s easy to imagine a system that is aligned, integrated and coherent but still not fit for purpose, and it’s just as easy to imagine a system that is not aligned, not integrated and not coherent but that is fit for purpose. Of course, we can insist that alignment, integration and coherency be with respect to a system’s purpose, but if that’s the case, why don’t we say so directly? Why use words that strongly suggest internal properties of the system rather than its relationship to an external purpose?
Whatever we call it, continuous pursuit of something is ultimately the continuous failure to achieve it. It isn’t the chase that matters, it’s the catch. While I am sympathetic to the idea that there is intrinsic value in “doing architecture,” the real value is in the resulting architecture and its implementation. Until we actually implement the architecture, we can only answer the question, “Are we there yet?” with, “No, not yet”.
Let me be clear that I’m not arguing, or even assuming, that things don’t change and we don’t need to cope with change. Of course they do, and of course we do. But we should take a cue from rock climbers – the ones who don’t fall generally follow the principle “only move one limb at a time, from a secure position.” What stakeholders mean by fitness for purpose must be periodically revisited and revised. It’s fashionable to say “Enterprise Architecture is a journey, not a destination,” and this is reflected in definitions of Enterprise Architecture that refer to it as a “continuous process.” However, the fact is that journey has to pass through specific waypoints. There may be no final destination, but there is always a next destination.
Finally, we should not forget that while the pursuit of fitness for purpose may require that some things change; it may also require that some things not change. We risk losing this insight if we conclude that the primary purpose of architecture is to enable change. The primary purpose of architecture is to ensure fitness for purpose.
For a fuller treatment of the connection between architecture and fitness for purpose, see my presentations to The Open Group Conferences in Boston, July 2010, “What ‘Architecture’ in ‘Enterprise Architecture’ Ought to Mean,” and Amsterdam, October 2010, “Deriving Execution from Strategy: Architecture and the Enterprise.”
Len Fehskens is Vice President of Skills and Capabilities at The Open Group. He is responsible for The Open Group’s activities relating to the professionalization of the discipline of enterprise architecture. Prior to joining The Open Group, Len led the Worldwide Architecture Profession Office for HP Services at Hewlett-Packard. Len is based in the US.
@Len: “Enterprise Architecture is thus about enterprise transformation.”
HI Len. You know I have the greatest respect for you but I believe in this respect you are not correct.
That is the simplistic view which causes everyone to pedal faster.
Enterprise Architecture is thus the transformation of enterprise transformation.
That’s about improving the bike!
That’s architecture.
Kevin: Please reread what I wrote. The whole rest of the piece pretty clearly shows my belief that EA is not about enterprise transformation. The clause you quote is preceded by the qualification that this is a consequence of the common belief that architecture is about change, which I then proceed to argue against.
len.
@Len: “Please reread what I wrote.”
Good point! I do admit I did tend to speed read it and lost its purpose.
I think it is a balance.
You are arguing for the phrase “fitness of purpose” and against that belief that architecture is about change.
I believe both are correct. One without the other is meaningless.
I am very uneasy though with this “fitness for purpose” statement. It seems a very loose term to me and open to massive interpretation – which of course is even worse when we are in the realisms of EA with its current mush of misunderstands and snake oil.
OK – so, we can all agree that “fitness for purpose” (whatever that means) is important but all your words are still around the transformation of operational processes people and technology.
The transformation of operational processes people and technology can be done without using architecture at any time at any level.
When I say “without using architecture” I mean without using the architecture paradigm (modelling and abstraction).
I would like to draw a distinction between
1) transformations programmes (big or small) that change the organisations operations and
2) transformations programmes that transform the way transformation programs are run.
In my experience, every single organisation is changing and does change.
Changing is not necessarily a differentiator anymore.
What is a differentiator (and even more so day by day) is how effective, efficient, agile and durable those changes are.
So, of course transformation programmes are, of course, important and we need someone to be accountable at board level for them however I am advocating that this persons accountability should be at least 50% devoted to improving the people, processes and technology used in transformation programs.
My experience is that many people find this important distinction difficult to comprehend (which is probably why organisations do not do anything about it, which is IMHO why so many transformation projects fail) but on the other hand it’s difficult to explain softly for fear of irritating or appearing to insult people.
It’s just information though – knowledge.
And a lack of knowledge is not the same as a lack of intelligence.
Most people I meet (and probably everyone on this forum) tend to be extremely intelligent so I am just highlighting some information that many appear not to see (And therefore do nothing about)
To highlight the problem (we can only get people to do something about it if they can see the problem in the first place) I ask all board members to consider these questions
1) Effectiveness – Are you happy that (for the majority of your change projects) they meet the strategic objectives they set out to achieve?
2) Efficiency – Are you happy that (for the majority of your change projects) they use the least amount of resources to accomplish their goal?
3) Agility – Are you happy that (for the majority of your change projects) that the change requested/required by the Business Strategy requires only small change projects?
4) Durability – Are you happy that (for the majority of your change projects) that the changes they make are used by the company for long periods of time without significant modification?
I agree that EA includes fitness for purpose as you have suggested. I feel that at same time, it should also cater to efficiency/quality (assuming that fitness for purpose is concurrently being achieved).
This is the concept that you will find in the ITIL best practice framework where they consider the end objective to be to achieve Value for the business – and this can only be achieved when both fitness for purpose (what ITIL calls “Utility”) and efficiency/quality (what ITIL calls “Warranty”) are catered for.
Goh Boon Nam: First, quality is a very ambiguous word. I take my cue from people like Philip Crosby and W. Edwards Deming, who define quality as conformance to specification. This applies to both quality of design and quality of implementation. Quality of design relates to the fitness for purpose, where the “specification” is what the stakeholders define as fit for purpose. Quality in this sense is “built into” my concept of architecture.
More importantly though, I am always astonished by the architect community’s (indeed, the entire IT community’s) assumption that they know better than the stakeholders what the stakeholders need.
“Quality”, however you define it, and “efficiency” are only proper goals of or constraints on an architecture if the stakeholders tell you they are. An architect can certainly suggest to stakeholders that certain properties of a solution should be considered, but it is ultimately the stakeholders’ decision as to what the architecture must address.
len.
Change is not a mean or an end but: “Change is occurring so rapidly in our society that we have no choice but to embrace it and make it work in our favor.” This is a quote from a book about real-world non-IT Enterprise Improvement/Architecture: “The Improvement Guide: A Practical Approach to Enhancing Organizational Performance”
They use a simple method/framework which can be explained to everybody in less than 3 minutes (http://www.youtube.com/watch?v=SCYghxtioIY&feature=related).
So what is the real value of Enterprise Architecture with all its complex models and vague definitions compared to what IHI (http://www.ihi.org/about/pages/default.aspx) is doing by using just this simple, understandable and explainable method?
It’s nice sentiment. But I dissagree strongly. (But mostly with primary bit.) My reason is very simple. Ensuring fitness for purpose is what Project / Programme / Portfoilio management is for. And PM is an established very mature profession with a lot of very capable practioners.
EA does itself no favors by arrogating to itself the prerogatives of sister functions.
And while EA is in my view a significant contributor to PM outcomes and provides input all the way along the project life cycle, it’s ‘primary’ aim surely should be something that is only achievable by EA. Something for which it is necessary.
I agree that ‘alignment’ is a furphy. I think it is an overused cliche.
Personally I have come to the conclusion that the primary purpose of EA is, and really can only be what the PEAF guy has been hanging on about… The reduction of technical debt. (Or ‘architectural debt’ as some call it.)
Large technical debts can accrue from the best run projects and from. High quality fit for purpose systems. It’s the only value I have. Even able to think of that EA and EA alone can provide.
For that reason I think it warrants the adjective ‘primary’.
Ric writes:
“Ensuring fitness for purpose is what Project / Programme / Portfoilio management is for.”
I have to disagree as strongly The purpose of project, program, or portfolio management is to, well, manage the project, program or portfolio. And these are three very different disciplines, If you really believe that that these managers are responsible for the fitness for purpose of systems and solutions, than I am pretty sure we don’t mean the same thing by “fitness for purpose”.
Of course project managers have an effect on fitness for purpose, by ensuring that the implementation is successful. But they don’t actually do the implementation, they plan and oversee it to ensure that the necessary resources are available when needed and that everything goes according to plan. The implementers do the actual implementation work, and it is their responsibility to ensure that the implementation conforms to the design.
Similarly, project managers don’t do the design. Again, they plan and oversee it to ensure that the necessary resources are available when needed and that everything goes according to plan. Designers do the actual design work, and it is their responsibility to ensure that the designed system or solution is fit for purpose.
Etc.
If you’re arguing that project managers are responsible for fitness for purpose by virtue of the fact they they are often charged with “gathering requirements”, I think several decades of experience with requirements churn and systems that satisfy these gathered requirements but do not deliver business value (i.e., are not fit for purpose) shows us that “gathering requirements” is probably not the right way to ensure fitness for purpose. I deal with this problem, and the relationship between architects and project and program mangers in the presentations I referenced at the end of my post, and other related presentations at The Open Group Conferences.
len.
@Len. Thanks for the post. What do you see as the difference between alignment and fitness for purpose? Is the alignment not to the purpose? If not what is the alignment to?
Good question. In the interest of brevity I only alluded to the idea that we can define alignment to mean fitness for purpose, but the question then becomes what is it that is being aligned, what is it that is fit for purpose, and what’s the relationship between these things. This ambiguity is why I prefer that if what we are really intending to achieve is fitness for purpose, we should call it fitness for purpose rather than something else that might be interpreted differently.
So, for example, what is being aligned? If the solution is being aligned with the need (what I call the mission), then yes, alignment can be synonymous with fitness for purpose. But if parts of the solution are being aligned amongst themselves, it is possible for the solution to be “internally aligned” while failing to be “externally aligned” with the mission.
The problem I have with much of the language we use to talk about architecture is that it more often than not reflects a solution-centric perspective, rather than a mission-centric perspective, and as such the solution often becomes an end in itself, rather than being thought of as a means to the achievement of the mission. The moment that shift in perspective occurs, the fitness for purpose of the solution for achieving the mission becomes at risk.
len.
@Len. Thanks for that. I have always assumed that alignment means, as you say, alignment to the mission. I typically think of it as alignment to the specified and agreed business outcome.(the same thing in different words.)
I have never considered that the term alignment could mean internal alignment only. I would certainly question any EA practitioner that does interpret it that way. Given that so many EAs start of as solution architects (SA) & given some recent experiences working with so SAs that thought they were EAs I can see how this is coming to be.
So basically I fully agree with you and thank you for opening my eyes to the possibility that there are people out there that may be interpreting alignment in the (misguided) internal-only way.
We have to be careful that we don’t make change an end in itself. We have to remember that change is a means to the end of getting something we want that is different from what we have. In the enterprise context, that something has been labeled in different ways. One is “alignment,” specifically “business/IT alignment.” Some have concluded that alignment isn’t quite the right idea, and it’s really “integration” we are pursuing. Others have suggested that “coherency” is a better characterization of what we want.
I think all of these are still just means to an end, and that end is fitness for purpose. The pragmatist in me says I don’t really care if all the parts of a system are “aligned” or “integrated” or “coherent,” as long as that system is fit for purpose, i.e., does what it’s supposed to do.
I’m sure some will argue that alignment and integration and coherency ensure that a system is “optimal” or “efficient,” but doing the wrong thing optimally or efficiently isn’t what we want systems to do. It’s easy to imagine a system that is aligned, integrated and coherent but still not fit for purpose, and it’s just as easy to imagine a system that is not aligned, not integrated and not coherent but that is fit for purpose.
Of course, we can insist that alignment, integration and coherency be with respect to a system’s purpose, but if that’s the case, why don’t we say so directly? Why use words that strongly suggest internal properties of the system, rather than its relationship to an external purpose?
Dana Gardner, Principal Analyst, Interarbor Solutions
Len,
Good post. I’m fascinated by the response. I understood you the phrase “fitness for purpose” to mean that the ENTIRE architecture is fit for the the purpose of fulfilling the mission of the business. Judging from the response, that sentiment was not universally understood.
I’d venture to guess that one reason is this: “fitness for purpose” can work against EA, if the purpose is the sub-optimization of the architecture for the fitness of a single project (one of the top scenarios that EA is responsible for avoiding). As you point out, Program and Project managers are often held accountable for delivering “according to spec” even if that spec describes a future state that is not feasible, is not reasonably rationalized, or does not meet long-term enterprise goals. Yet those same folks will argue that their project is delivering, and can be measured, on it’s “fitness for purpose.”
I like where your post went, but I wonder if we can say that the architecture, as a whole, displays the attribute of “fitness for mission?”
It’s a good post.
— Nick
Nick – you’ve raised another issue that I’ve tried to address in my longer treatments of this subject.
I believe architecture is about fitness for purpose in that an architecture specifies those properties of an artifact that are necessary and sufficient for that artifact to be fit for purpose (for the moment let’s leave out properties of the artifact’s mission, i.e., what it’s supposed to be or do, and its environment, just to keep the discussion simple). It’s the artifact’s fitness for purpose that we care about, and it’s the architecture of the artifact that ensures that the artifact is fit for purpose.
The question of how architecture differs from design is another long discussion, and I don’t want to get into that here, but the essence of it is that design includes all the other questions that architecture doesn’t answer, because though they need to be answered, there are multiple answers that are acceptable, unlike the architecture questions, which have to be answered a particular way to ensure the fitness for purpose of the artifact.
Now, an architecture is itself an artifact, and as such, ought to be fit for purpose. But the way we judge the fitness for purpose of an architecture is not the same way we judge the fitness for purpose of the artifact the architecture specifies. Clearly, one of the criteria must be that the architecture ensures the fitness for purpose of the artifact, but that’s tautological if that’s how we define architecture. It amounts to saying that the architecture has to be an architecture. The interesting question is what does it mean for an architecture to be fit for purpose, as an artifact of the class “architecture”? Answering this question requires applying an architectural approach to the discipline itself, and this recursive applicability has figured very strongly in the way I have approached the problem of defining architecture in general and enterprise architecture in particular.
len.
@Nick,
Spot on as always. I’ve been thinking about this overnight and agree with you that the entire architecture needs to be fit for mission and would also agree that each project should contribute to the overall fitness for mission.
@Len & @Nick
One thing that I have been asking myself overnight is whether the fitness for mission idea is complete. The reason that I say this is because ever changing enterprise context will require ever changing solutions. I’m not sure yet that this notion of ‘fitness’ inherently accounts for the need for adaptability.
If by using the term ‘fitness’, we ARE including ideas of adaptability, build-for-change, etc, then that is great. This additional attribute would distinguish Len’s new idea of fitness for purpose from the traditional idea of alignment. I like that very much.
This leaves me with the tiny reservation that ‘fitness for mission’ may not express this attribute of a need for adaptability, sufficiently for people to inherently understand that the term ‘fitness for mission’ does in fact include notions that reflect changing context. In this case I would augment the term ‘fitness for purpose / mission’ with something that expressly reflects the need for adaptability.
Regarding “adaptability”:
I am continually surprised by the presumption of architects to know better than stakeholders what it is that stakeholders need (i.e., how they will define “fit for purpose”). Over the three and half decades that I have been doing architecture, the architecture community as a whole has shared many such presumptions, and the latest is adaptability. A few years ago it was security. Before that it was manageability. There’s always going to be some ‘-ity” or “-ility” that “everybody knows” must be addressed by every architecture, without qualification.
Now hear this: only the stakeholders of the artifact being architected know what constitutes that artifact’s fitness for purpose. It is the architect’s responsibility to draw that knowledge out from the stakeholders, and reconcile any contradictions or conflicts in the stakeholders’ collective understanding of what being fit for purpose entails. A competent architect certainly can and should suggest things that the stakeholders ought to consider as possibly contributing to fitness for purpose, but an architect who assumes a priori that something is always essential to achieving fitness for purpose for any and all missions is stepping on the stakeholders’ prerogatives.
len.
Excellent! Thanks Len. This has been a great post and associated comments. I have learned 2 or 3 good lessons from them. I am grateful to you and Nick in particular for your comments.