Great tweet from @judyrees this morning. "Metaphor can create powerful insights that become distortions, as the way of seeing created through metaphor becomes a way of not seeing."
When people talk about the "alignment" or "gap" between business and technology, is this just a rhetorical metaphor, or is it supposed to have a literal meaning?
I can easily understand the concepts of "alignment" and "gap" when we are talking about similar things in the same space. For example, there is a gap between my house and the house next door, and both are roughly aligned with the houses opposite. I understand what these terms mean geometrically (literally "earth-measurement") and could measure them to a reasonable degree of accuracy.
However, if someone started to talk about the "alignment" between his love life and the works of Shakespeare, I could only really make sense of this as an interesting metaphor. It would be absurd to try and measure this kind of alignment using geometrical instruments.
In order to take the notion of business-IT alignment seriously (i.e. as more than just a metaphor), we have to have some way of understanding "business" and IT" to be similar objects within the same kind of space. One possible way of doing this would be to define a distance relationship between the IT department and other parts of the organization, in terms of the interaction and coordination between separate organization units. As it happens, I did some work in the 1990s on enterprise modelling, where we experimented with the notion of "interaction distance", although I think I'd now call this "collaboration distance".
This is perhaps what is implied in a recent Strategy+Business article, which identified enterprise architecture as a way of "closing the distance between IT departments and business units" [Hugo Trepant and Daniel Newman, Strategy by Design, August 2010, via @andrewtuson].
The notion of collaboration distance can also be used to help understand the degree of alignment or misalignment between separate business organizations in the context of a complex business relationship - for example the relationship between Ford and Firestone. (See my post on Supplier Abuse.)
An alternative interpretation comes from George Ambler (@CIOLeader) who suggests that "it is the mindset gap between biz and IT that's the biggest gap of all". To interpret this literally, one would need a way of measuring the distance between two mindsets, and comparing distances between three, but at least we are talking here about notional alignments and gaps between instances of a common class.
Where I have greatest problems with the notion of business-IT alignment is where "business" and "IT" are spoken of as complex wholes apparently occupying completely different spaces. Of course, one possible tactic for enterprise architects is to produce a simplified representation of "business" and a simplified representation of "IT" within a chosen EA framework or modelling language, and then to define "alignment" in terms of some congruence relationship between the two representations. But we should be both surprised and deeply unimpressed if enterprise architecture were unable to manufacture this kind of simplified alignment, and we should be wary of circular arguments that promote the value and validity of these frameworks in terms of alignment while simultaneously defining alignment in terms of these frameworks.
Finally, I want to draw attention to a significant weakness in current enterprise architecture thinking and practice. Despite the constant rhetoric of alignment, the models and frameworks in common use provide no basis for reasoning about alignment, with all its costs and complexities. Enterprise architects profess to understand structure, but there are some important aspects of structure that are generally not addressed.
Showing posts with label alignment. Show all posts
Showing posts with label alignment. Show all posts
Friday, November 05, 2010
Wednesday, September 15, 2010
The Future of Enterprise Architecture
Let's start with the positive.
Enterprise architects are mostly pretty skilled at identifying duplication, inconsistency and lack of interoperability across complex systems of systems, which they regard as fragmentation and waste. As a consequence, theytypically often set themselves a mission of simplification and unification. For some, this mission is largely confined to IT systems; for others, this mission may extend to business processes and the entire business operation.
In pursuing this mission, they find themselves opposed to narrow or short-term thinking from various stakeholders - line managers wanting quick and cheap solutions to local problems, project managers or external contractors trying to meet tight project goals, infrastructure managers wanting to protect established assets and arrangements. A committed enterprise architect will therefore get into a series of battles inside the organization, defending the principles of simplification and unification. (An uncommitted enterprise architect will withdraw from these battles and devote energy to producing abstract plans that will be ignored by everyone else - but it's difficult to see any value whatsoever in this kind of disengagement.)
The primary weapon in these battles is the Plan - an abstract blueprint that represents an idealized TO-BE architecture. This Plan needs to embody the principles of simplification and unification, not only because that's the mission, but also because that's the only way it's going to make sense to senior management, without whose support the battles cannot be won. The Plan is therefore not just a weapon but a story, perhaps even a myth.
But here's the problem: real business is inherently complex. Therefore battles against complexity (not always, but often enough to cause concern) are ultimately battles against the business. Or worse - against the customers of the business.
The mission to simplify and unify has undoubtedly had some successes, but it has also produced some massive failures - projects that have gone way over budget without coming anywhere close to delivering the promised business benefits. Some of the best-known examples can be found in the public sector because these are open to public scrutiny, but the private sector is not immune to this kind of failure. In the UK this week, the National Programme for IT in the health service has been finally put out of its misery, following cancellation of a number of other projects that were supposed to deliver both improved outcomes and massive cost savings.
To the extent that projects like this appear to be following an old-style enterprise architecture agenda, these failures serve to undermine the credibility of enterprise architecture in the eyes of many stakeholders, and should pose a series of hard questions for enterprise architecture practice.
Of course enterprise architects could try to attribute all such failures to errors of execution rather than errors of intention or planning (in other words, the vision was okay, the overall plan was okay, but the project managers screwed up). Alternatively, they could try to find fault with each of the failed plans, identifying ways in which these plans disobeyed some of the core principles of enterprise architecture.
But I believe these examples force us to do something more fundamental - to rethink the mission of enterprise architecture. If the mission to simplify and unify conflicts with the mission to "align" (whatever that means) with the business, then perhaps enterprise architects need to find a new mission.
Simplification and unification is merely a strategy in the management of complexity. As I see it the enterprise architect's job is not to manage-away the complexity of business or IT, but to find ways to make the complexity more manageable.
More manageable for whom? Just about anybody. Business line managers need to be able to manage the complexity of their business operation, and the top management team needs to be able to manage the complexity of the whole organization. Meanwhile, business support managers (such as IT and HR) need to be able to manage the complexity of their own domain as well as providing specialist support for the rest of the organization.
Thus the enterprise architect should be helping the CIO answer the following two questions.
Enterprise architects are mostly pretty skilled at identifying duplication, inconsistency and lack of interoperability across complex systems of systems, which they regard as fragmentation and waste. As a consequence, they
In pursuing this mission, they find themselves opposed to narrow or short-term thinking from various stakeholders - line managers wanting quick and cheap solutions to local problems, project managers or external contractors trying to meet tight project goals, infrastructure managers wanting to protect established assets and arrangements. A committed enterprise architect will therefore get into a series of battles inside the organization, defending the principles of simplification and unification. (An uncommitted enterprise architect will withdraw from these battles and devote energy to producing abstract plans that will be ignored by everyone else - but it's difficult to see any value whatsoever in this kind of disengagement.)
The primary weapon in these battles is the Plan - an abstract blueprint that represents an idealized TO-BE architecture. This Plan needs to embody the principles of simplification and unification, not only because that's the mission, but also because that's the only way it's going to make sense to senior management, without whose support the battles cannot be won. The Plan is therefore not just a weapon but a story, perhaps even a myth.
But here's the problem: real business is inherently complex. Therefore battles against complexity (not always, but often enough to cause concern) are ultimately battles against the business. Or worse - against the customers of the business.
The mission to simplify and unify has undoubtedly had some successes, but it has also produced some massive failures - projects that have gone way over budget without coming anywhere close to delivering the promised business benefits. Some of the best-known examples can be found in the public sector because these are open to public scrutiny, but the private sector is not immune to this kind of failure. In the UK this week, the National Programme for IT in the health service has been finally put out of its misery, following cancellation of a number of other projects that were supposed to deliver both improved outcomes and massive cost savings.
To the extent that projects like this appear to be following an old-style enterprise architecture agenda, these failures serve to undermine the credibility of enterprise architecture in the eyes of many stakeholders, and should pose a series of hard questions for enterprise architecture practice.
Of course enterprise architects could try to attribute all such failures to errors of execution rather than errors of intention or planning (in other words, the vision was okay, the overall plan was okay, but the project managers screwed up). Alternatively, they could try to find fault with each of the failed plans, identifying ways in which these plans disobeyed some of the core principles of enterprise architecture.
But I believe these examples force us to do something more fundamental - to rethink the mission of enterprise architecture. If the mission to simplify and unify conflicts with the mission to "align" (whatever that means) with the business, then perhaps enterprise architects need to find a new mission.
Simplification and unification is merely a strategy in the management of complexity. As I see it the enterprise architect's job is not to manage-away the complexity of business or IT, but to find ways to make the complexity more manageable.
More manageable for whom? Just about anybody. Business line managers need to be able to manage the complexity of their business operation, and the top management team needs to be able to manage the complexity of the whole organization. Meanwhile, business support managers (such as IT and HR) need to be able to manage the complexity of their own domain as well as providing specialist support for the rest of the organization.
Thus the enterprise architect should be helping the CIO answer the following two questions.
- How can I manage the complexity of IT operations, systems and services?
- How can IT contribute to managing the complexity of the rest of the organization (including other support functions)?
- How can I manage the complexity of people management?
- How can I help develop the capability of the whole organization to collectively manage complexity?
The IT department can support the management of complexity across the organization by providing a set of useful tools, including business intelligence tools, decision support tools, social networking tools and so on. (The provision of management information has always been a major responsibility of the IT department, and this cannot be done properly without understanding how and why management information is used.) The HR department has a different set of tools, such as training programmes, incentive packages, career paths, and so on. The enterprise architect's role here is not to manage the detailed implementation of all these different tools, but to understand the overall structural requirements and implications.
Architecture is basically about structure. Business is facing some increasing complex structural problems, and the primary task for enterprise architects is to tackle these structural problems. Tackle, not solve. The collective ability of the whole organization to manage the essential complexity of demand, from customers and the rest of the environment, depends strongly (although not solely) on the emergent structure of the organization and its systems, and this is where the enterprise architect's attention should be focused.
Related posts: Who architects the organization? (September 2010), Complexity is not a problem (February 2013)
Updated 16 January 2013. Links added 12 September 2021
Thursday, June 10, 2010
Ecosystem SOA 2
What are the problems of large complex sociotechnical systems? How far do SOA and enterprise architecture help to address this problem space, and what else might we need?
When I started writing about SOA and the service-based business over ten years ago, I defined two "cuts" across the service ecosystem. One cut separates inside from outside, while the other cut separates supply from demand.
(This diagram was included in my 2001 book on the Component-Based Business, and frequently referenced in my work for the CBDI Forum. For a brief extract from the book, see my Slideshare presentation on the Service Ecosystem.)
The inside/outside cut is sometimes called encapsulation. It decouples the external behaviour of a service from its internal implementation, and can be described in terms of knowledge - the outside has limited knowledge of the inside, and vice versa. (The cut is also sometimes called transparency - for example location transparency, which means that external viewers can't see where something is located.)
The supply/demand cut is about delegation, and can be described in terms of responsibility. Getting these two cuts right may yield economics of scale and scope; and the business case for SOA as a development paradigm is often formulated in terms of reusing and repurposing shared services.
For relatively small and simple SOA projects, it may be feasible to collapse the difference between these two cuts, and treat them as equivalent. (The inside/outside relationship and the supply/demand relationship are sometimes both described as "contracts", although they are clearly not the same kind of contract.) However, enterprise-scale SOA requires a proper articulation of both cuts: confusing them can result in suboptimal if not seriously dysfunctional governance and procurement. Many people in the SOA world still fail to understand the conceptual importance of these cuts, and this may help to explain why some organizations have had limited success with enterprise-scale SOA.
Going beyond enterprise SOA as it is generally understood, there is a third cut separating two views of a system: the system-as-designed (whose structure and behaviour and rules can perhaps be expressed in some formal syntax such as UML, BPMN or ArchiMate) and the system-in-use (whose actual performance is embedded/situated in a particular social or business context). This cut is critical for technology change management, because of the extent to which the designed system underdetermines the pragmatics of use. I have been talking about this cut for over twenty years, but only more recently working out how to articulate this cut in composition with the other two cuts.
One important reason for looking at the pragmatics of use is to understand the dimensions of agility. In many settings, we can see a complex array of systems and services forming a business platform, supporting a range of business activities. If no agility is required in the business, then it may not matter if the platform is inflexible, forcing the business activities to be carried out in a single standardized manner. But if we assume that agility is a critical requirement, then we need to understand how the flexibility of the platform supports the requisite variety of the business.
More generally, understanding the pragmatics of use leads to the recognition of a third kind of economic value alongside the economics of scale and the economics of scope: the economics of alignment. The value of a given system-of-systems depends on how it is used to deliver real (joined-up) business outcomes, across the full range of business demands. (I'm afraid I get impatient with people talking glibly and simplistically about business/IT alignment, without paying attention to the underlying complexity of this relationship.)
Understanding these three cuts (and analysing their implications) is critical to understanding and managing a whole range of complex systems problems - not just SOA and related technologies, not even just software architecture, but any large and complex sociotechnical systems (or systems-of-systems). If the three cuts are not understood, the people in charge of these systems tend not to ask the right questions. Questions of pragmatics are reduced to questions of platform design; while questions of the cost-justification and adoption of the platform are reduced to a simple top-down model of business value. Meanwhile the underlying business complexity (requisite variety) will be either misplaced (e.g. buried in the platform) or suppressed (e.g. constrained by the platform).
So there are three challenges I face as a consultant, attempting to tackle this kind of complex problem. The first challenge is to open up a new way of formulating the presenting problem, based on the three cuts. The second challenge is to introduce systematic techniques for analysing the problem and visualizing the key points. And the third challenge is to identify and support any organizational change that may be needed.
With thanks to Philip Boxer and Bernie Cohen. For a different formulation of the three cuts, together with a detailed example, see their new paper "Why Critical Systems Need Help to Evolve" Computer, vol. 43, no. 5, pp. 56-63, May 2010, doi:10.1109/MC.2010.150. See also Philip Boxer, When is a stratification not a universal hierarchy? (January 30th, 2007)
Related post Ecosystem SOA (October 2009)
When I started writing about SOA and the service-based business over ten years ago, I defined two "cuts" across the service ecosystem. One cut separates inside from outside, while the other cut separates supply from demand.
(This diagram was included in my 2001 book on the Component-Based Business, and frequently referenced in my work for the CBDI Forum. For a brief extract from the book, see my Slideshare presentation on the Service Ecosystem.)
The inside/outside cut is sometimes called encapsulation. It decouples the external behaviour of a service from its internal implementation, and can be described in terms of knowledge - the outside has limited knowledge of the inside, and vice versa. (The cut is also sometimes called transparency - for example location transparency, which means that external viewers can't see where something is located.)
The supply/demand cut is about delegation, and can be described in terms of responsibility. Getting these two cuts right may yield economics of scale and scope; and the business case for SOA as a development paradigm is often formulated in terms of reusing and repurposing shared services.
For relatively small and simple SOA projects, it may be feasible to collapse the difference between these two cuts, and treat them as equivalent. (The inside/outside relationship and the supply/demand relationship are sometimes both described as "contracts", although they are clearly not the same kind of contract.) However, enterprise-scale SOA requires a proper articulation of both cuts: confusing them can result in suboptimal if not seriously dysfunctional governance and procurement. Many people in the SOA world still fail to understand the conceptual importance of these cuts, and this may help to explain why some organizations have had limited success with enterprise-scale SOA.
Going beyond enterprise SOA as it is generally understood, there is a third cut separating two views of a system: the system-as-designed (whose structure and behaviour and rules can perhaps be expressed in some formal syntax such as UML, BPMN or ArchiMate) and the system-in-use (whose actual performance is embedded/situated in a particular social or business context). This cut is critical for technology change management, because of the extent to which the designed system underdetermines the pragmatics of use. I have been talking about this cut for over twenty years, but only more recently working out how to articulate this cut in composition with the other two cuts.
One important reason for looking at the pragmatics of use is to understand the dimensions of agility. In many settings, we can see a complex array of systems and services forming a business platform, supporting a range of business activities. If no agility is required in the business, then it may not matter if the platform is inflexible, forcing the business activities to be carried out in a single standardized manner. But if we assume that agility is a critical requirement, then we need to understand how the flexibility of the platform supports the requisite variety of the business.
More generally, understanding the pragmatics of use leads to the recognition of a third kind of economic value alongside the economics of scale and the economics of scope: the economics of alignment. The value of a given system-of-systems depends on how it is used to deliver real (joined-up) business outcomes, across the full range of business demands. (I'm afraid I get impatient with people talking glibly and simplistically about business/IT alignment, without paying attention to the underlying complexity of this relationship.)
Understanding these three cuts (and analysing their implications) is critical to understanding and managing a whole range of complex systems problems - not just SOA and related technologies, not even just software architecture, but any large and complex sociotechnical systems (or systems-of-systems). If the three cuts are not understood, the people in charge of these systems tend not to ask the right questions. Questions of pragmatics are reduced to questions of platform design; while questions of the cost-justification and adoption of the platform are reduced to a simple top-down model of business value. Meanwhile the underlying business complexity (requisite variety) will be either misplaced (e.g. buried in the platform) or suppressed (e.g. constrained by the platform).
So there are three challenges I face as a consultant, attempting to tackle this kind of complex problem. The first challenge is to open up a new way of formulating the presenting problem, based on the three cuts. The second challenge is to introduce systematic techniques for analysing the problem and visualizing the key points. And the third challenge is to identify and support any organizational change that may be needed.
With thanks to Philip Boxer and Bernie Cohen. For a different formulation of the three cuts, together with a detailed example, see their new paper "Why Critical Systems Need Help to Evolve" Computer, vol. 43, no. 5, pp. 56-63, May 2010, doi:10.1109/MC.2010.150. See also Philip Boxer, When is a stratification not a universal hierarchy? (January 30th, 2007)
Related post Ecosystem SOA (October 2009)
Thursday, December 31, 2009
Alignment as a Percentage
Many people perceive value in something called Business-IT alignment, and argue that we should invest in tools and methods that increase this alignment.
Does the word "alignment" actually mean anything concrete, or is it just a vague metaphor, as I suggested in my previous post Alignment - Science or Pseudoscience? Here's my challenge to the alignment brigade: I'm not interested in "business-IT alignment" unless it can be expressed as a percentage.
Let's imagine we can define a scale from 0% (no alignment whatsoever) to 100% (total alignment). I guess the two extremes would be practically impossible, but 80% would be significantly better than 40%. So we could suppose that any investment that increased alignment from 40% to 80% would be worth considering, if the costs and risks were acceptable.
But at present, we don't have an agreed scale. People sometimes talk as if alignment was some metaphysical goal (like love), rather than a practical manageable outcome. But while I accept the importance of relationships and trust within organizations, I don't see this as part of the concept of alignment.
And I'm not convinced that Business-IT alignment is necessarily a good thing anyway. As I said at a CBDI Forum meeting back in April 2000,
Furthermore, why is "alignment" only a question for IT. @malcolmlowe comments "interesting how no-one measures business-finance alignment as %. It's just part of bus". And what about HR or other support functions?
However if we had a scale I believe it could be a useful management tool, provided that the results were properly interpreted. Given how many CIOs worry about the "alignment" problem, some of them might want to assess and benchmark the alignment percentage from time to time, to see if it is going up or down. As long as it is clearly understood that there are many things that IT needs to be "aligned" with, not just a simplistic notion of "the business".
Does the word "alignment" actually mean anything concrete, or is it just a vague metaphor, as I suggested in my previous post Alignment - Science or Pseudoscience? Here's my challenge to the alignment brigade: I'm not interested in "business-IT alignment" unless it can be expressed as a percentage.
Let's imagine we can define a scale from 0% (no alignment whatsoever) to 100% (total alignment). I guess the two extremes would be practically impossible, but 80% would be significantly better than 40%. So we could suppose that any investment that increased alignment from 40% to 80% would be worth considering, if the costs and risks were acceptable.
But at present, we don't have an agreed scale. People sometimes talk as if alignment was some metaphysical goal (like love), rather than a practical manageable outcome. But while I accept the importance of relationships and trust within organizations, I don't see this as part of the concept of alignment.
And I'm not convinced that Business-IT alignment is necessarily a good thing anyway. As I said at a CBDI Forum meeting back in April 2000,
"There are some organizations where business and IT are perfectly aligned: they are standing side by side, with their heads in the same sand, aligned in a shared sense of complacency. In other organizations, the opposite is true. It is often in the dynamic, progressive organizations where business and IT are furthest apart." [CBDI Journal "Interact", May 2000]
Furthermore, why is "alignment" only a question for IT. @malcolmlowe comments "interesting how no-one measures business-finance alignment as %. It's just part of bus". And what about HR or other support functions?
However if we had a scale I believe it could be a useful management tool, provided that the results were properly interpreted. Given how many CIOs worry about the "alignment" problem, some of them might want to assess and benchmark the alignment percentage from time to time, to see if it is going up or down. As long as it is clearly understood that there are many things that IT needs to be "aligned" with, not just a simplistic notion of "the business".
Wednesday, December 30, 2009
Alignment - Science or Pseudoscience?
@RSessions claims that "Simplification occurs when the IT partitions align with the business partitions". But what does alignment mean?
Roger defines alignment as "a measure of how well two patterns overlay on top of each other". But this definition only works between two patterns that already occupy the same space.
For example, I think I know what it means to say that the furniture is aligned with the walls of the room, because I can measure this fact with geometrical instruments (ruler, set square), but if someone says that the colour of the furniture is aligned with the sensibilities of the owner, I can only make sense of this as a vague metaphor rather than a precise measurable fact.
The fallacy of astrology does not lie in the detailed analysis of alignments between the planets and stars - which after all occupy the same astronomical space - but in the notion that the movements of the planets against the stars are somehow aligned with the patterns of human affairs on earth. (And the reason this counts as pseudo-science is that the detailed correlation between sky and earth relies on an interpretation by an astrologer.)
When people talk about business-IT alignment, I can only make sense of this as a metaphor. I am not aware of a robust and meaningful formalization that would permit both business and IT to occupy the same geometrical space, and I can't see the point of inventing one.
All we need is a mapping between two patterns occupying different spaces. An alignment is a special kind of mapping within a fixed geometrical space. If we can't define a fixed geometrical space, then I regard the concept of "alignment" is a misleading metaphor, introducing unnecessary complication. I prefer the general concept of mapping to the false metaphor of alignment.
@aleksb6 objects that my position is "true iff two patterns to map. reality is a M2M relationship, so 'alignment' is not a complication, it's a necessity!" He continues "btw, isn't mapping two patterns just another instance of point-to-point thinking? I thought we wanted to discourage that!"
If alignment doesn't make sense between two things, I can't see that it makes any more sense between three or more things. The desired outcome is a set of structure-preserving mappings between as many things as we need to coordinate. That doesn't mean we can or should design each mapping separately. In all but the most trivial situations, however skilfully we decompose a large problem into subproblems, there is always some coordination (juggling) left to do.
Here's the bottom line. If assertions about business-IT alignment are to mean anything at all, then you have to have a way of looking at a lump of business and a lump of IT and say whether they are aligned or not, and if so how much.
Of course, if you believe you have a modelling language that can express both business and IT, then you might think all you have to do to find out if business and IT are aligned is to compare two models. But this turns out to a circular procedure, because the modelling languages are themselves justified by the claim that they promote business-IT alignment, so we cannot use the modelling languages themselves to prove that business-IT alignment has been achieved. There has to be some point of reference outside the modelling languages.
People keep telling me "alignment" is important, but they can only define it as a woolly and subjective metaphor. So if we stop worrying about "alignment", and talk instead about the various multi-dimensional mappings between a complex system of systems and a complex set of business requirements, we can concentrate on what is objectively important.
And leave the concept of "alignment" for the astrologers. All together now ...
Roger defines alignment as "a measure of how well two patterns overlay on top of each other". But this definition only works between two patterns that already occupy the same space.
For example, I think I know what it means to say that the furniture is aligned with the walls of the room, because I can measure this fact with geometrical instruments (ruler, set square), but if someone says that the colour of the furniture is aligned with the sensibilities of the owner, I can only make sense of this as a vague metaphor rather than a precise measurable fact.
The fallacy of astrology does not lie in the detailed analysis of alignments between the planets and stars - which after all occupy the same astronomical space - but in the notion that the movements of the planets against the stars are somehow aligned with the patterns of human affairs on earth. (And the reason this counts as pseudo-science is that the detailed correlation between sky and earth relies on an interpretation by an astrologer.)
When people talk about business-IT alignment, I can only make sense of this as a metaphor. I am not aware of a robust and meaningful formalization that would permit both business and IT to occupy the same geometrical space, and I can't see the point of inventing one.
All we need is a mapping between two patterns occupying different spaces. An alignment is a special kind of mapping within a fixed geometrical space. If we can't define a fixed geometrical space, then I regard the concept of "alignment" is a misleading metaphor, introducing unnecessary complication. I prefer the general concept of mapping to the false metaphor of alignment.
@aleksb6 objects that my position is "true iff two patterns to map. reality is a M2M relationship, so 'alignment' is not a complication, it's a necessity!" He continues "btw, isn't mapping two patterns just another instance of point-to-point thinking? I thought we wanted to discourage that!"
If alignment doesn't make sense between two things, I can't see that it makes any more sense between three or more things. The desired outcome is a set of structure-preserving mappings between as many things as we need to coordinate. That doesn't mean we can or should design each mapping separately. In all but the most trivial situations, however skilfully we decompose a large problem into subproblems, there is always some coordination (juggling) left to do.
Here's the bottom line. If assertions about business-IT alignment are to mean anything at all, then you have to have a way of looking at a lump of business and a lump of IT and say whether they are aligned or not, and if so how much.
Of course, if you believe you have a modelling language that can express both business and IT, then you might think all you have to do to find out if business and IT are aligned is to compare two models. But this turns out to a circular procedure, because the modelling languages are themselves justified by the claim that they promote business-IT alignment, so we cannot use the modelling languages themselves to prove that business-IT alignment has been achieved. There has to be some point of reference outside the modelling languages.
People keep telling me "alignment" is important, but they can only define it as a woolly and subjective metaphor. So if we stop worrying about "alignment", and talk instead about the various multi-dimensional mappings between a complex system of systems and a complex set of business requirements, we can concentrate on what is objectively important.
And leave the concept of "alignment" for the astrologers. All together now ...
When the Moon is in the 7th house and Jupiter aligns with Mars
Then peace will guide the planets and love will steer the stars.
Wednesday, September 02, 2009
Economics of agility 2
In my previous post on the Economics of Agility, I noted how little material has been published on this topic.
As Nicholas Whittall and Philip Boxer point out in their contribution to the recent debate on The Meaning of Value-for-Money in Defence Acquisition (RUSI, February 2009), there is an important link between agility and alignment. See also their earlier piece on Agility and Innovation in Acquisition (RUSI, February 2008).
The first observation is that defence acquisition - just like systems acquisition most anywhere - operates on a much slower tempo than the requirements of the business. The "business" of a military organization is running military campaigns; thus when writing for the defence community, Whittall and Boxer refer to the Campaign Tempo and the Acquisition Tempo.
The second observation is that there is a complex set of activities (such as orchestration, customization, and improvisation) involved in bridging between Demand (the demands of the campaign or business) and Supply (the procurement of specific systems and devices). These activities operate on an intermediate tempo, which Whittall and Boxer call the Alignment Tempo.
As Nicholas Whittall and Philip Boxer point out in their contribution to the recent debate on The Meaning of Value-for-Money in Defence Acquisition (RUSI, February 2009), there is an important link between agility and alignment. See also their earlier piece on Agility and Innovation in Acquisition (RUSI, February 2008).
The first observation is that defence acquisition - just like systems acquisition most anywhere - operates on a much slower tempo than the requirements of the business. The "business" of a military organization is running military campaigns; thus when writing for the defence community, Whittall and Boxer refer to the Campaign Tempo and the Acquisition Tempo.
The second observation is that there is a complex set of activities (such as orchestration, customization, and improvisation) involved in bridging between Demand (the demands of the campaign or business) and Supply (the procurement of specific systems and devices). These activities operate on an intermediate tempo, which Whittall and Boxer call the Alignment Tempo.
"Meeting the campaign tempo then depends on the alignment tempo possible, which in turn depends on the acquisition tempo at which gaps can be filled. Any slowness in acquisition tempo leads to increased bricolage and process short cuts to enable the alignment tempo to keep up with the campaign tempo. Thus, ‘agility’ finds its richest expression in the ability of the alignment tempo to meet the required campaign tempo at the lowest cost – i.e. to maximise the value-for-defence."
The challenge is then to produce just enough variety within the acquisition to optimize the economics of alignment. Boxer has developed a technique of Cohesion-Based Costing (not yet published), which "offers a means to attach a value to the cost of introducing flexibility". This kind of technique will clearly be of enormous benefit within the SOA world.
Related post Enterprise Tempo (October 2010)
Thursday, August 20, 2009
Enterprise Suffix - Companies as Categories
@tetradian Tom Graves is annoyed at Enterprise 2.0. He (rightly) complains that the term as defined by Andrew McAfee refers to software, and tries to construct an alternative definition that is more business-oriented.
While I agree with his complaint, I am not convinced that a business-oriented definition of "Enterprise 2.0" is a worthwhile exercise. The "2.0" suffix is inextricably linked to the software paradigm; it is a metaphor for strict version control, and really only makes sense to software engineers and dictators. To produce the Third Reich (or as we should now call it "Reich 3.0") required a massive amount of centralized control and alignment (known as Gleichschaltung).
Software engineers who want to sound cool often use names instead of numbers. Apple operating systems are named after large cats, so we might have something like Enterprise Snow Leopard. (Thanks to Ron Tolido.) Microsoft plays this game as well - see my post on Google and Longhorn.
Software people may describe enterprises in terms of version numbers, but how do business people describe enterprises? Usually by comparing with something else. Listen to how entrepreneurs bid for venture capital. "It's going to be like eBay with a dash of vodka." "It's going to combine the innovation of Google with the popularity of er Google." In other words, they tell stories and paint pictures.
At any given time, there are a few companies that everyone wants to emulate - not just in terms of market share and profit, but also in terms of the internal management and organization - typically based on descriptions in the popular business literature. One of the early classics of this genre was Peters and Waterman, In Search of Excellence, which held up several American firms for admiration and emulation. (These recommendations look really dated now; and as Jason Cohen points out, Business Advice is Plagued by Survivor Bias.) In the heyday of quality management, many people tried to emulate Xerox and Motorola. More recently, Joshua Cooper Ramo, in a book called The Age of the Unthinkable, identifies Google and Hizb'allah as two of the most innovative organizations of our time.
Therefore if we must have an enterprise suffix, and if we want this to be meaningful to business people, let's use well-known companies as the categories. So if you want to emulate Google, then you need to implement Enterprise-a-Google.
Not perfect I agree, but anything's better than these dammed version numbers.
While I agree with his complaint, I am not convinced that a business-oriented definition of "Enterprise 2.0" is a worthwhile exercise. The "2.0" suffix is inextricably linked to the software paradigm; it is a metaphor for strict version control, and really only makes sense to software engineers and dictators. To produce the Third Reich (or as we should now call it "Reich 3.0") required a massive amount of centralized control and alignment (known as Gleichschaltung).
Software engineers who want to sound cool often use names instead of numbers. Apple operating systems are named after large cats, so we might have something like Enterprise Snow Leopard. (Thanks to Ron Tolido.) Microsoft plays this game as well - see my post on Google and Longhorn.
Software people may describe enterprises in terms of version numbers, but how do business people describe enterprises? Usually by comparing with something else. Listen to how entrepreneurs bid for venture capital. "It's going to be like eBay with a dash of vodka." "It's going to combine the innovation of Google with the popularity of er Google." In other words, they tell stories and paint pictures.
At any given time, there are a few companies that everyone wants to emulate - not just in terms of market share and profit, but also in terms of the internal management and organization - typically based on descriptions in the popular business literature. One of the early classics of this genre was Peters and Waterman, In Search of Excellence, which held up several American firms for admiration and emulation. (These recommendations look really dated now; and as Jason Cohen points out, Business Advice is Plagued by Survivor Bias.) In the heyday of quality management, many people tried to emulate Xerox and Motorola. More recently, Joshua Cooper Ramo, in a book called The Age of the Unthinkable, identifies Google and Hizb'allah as two of the most innovative organizations of our time.
Therefore if we must have an enterprise suffix, and if we want this to be meaningful to business people, let's use well-known companies as the categories. So if you want to emulate Google, then you need to implement Enterprise-a-Google.
Not perfect I agree, but anything's better than these dammed version numbers.
Sunday, March 15, 2009
Business Strategy and Alignment
Which relationships dominate an organization? Some organizations are driven by customer relationships, some by partner/supplier relationships, and some by technology and research.
One of the ideas I picked up many years ago from a paper by Professor Joseph Tidd was the strategic importance of this choice: which external relationships are dominant, and how this affects the internal power relationships within the organization.
Obviously such business strategies will need to be supported by information systems that communicate across and between organizations in an appropriate manner. Some strategies may require so-called Chinese walls, providing a level of protection from information leaking prematurely to competitors. Some strategies require a degree of proximity bordering on intimacy - business jargon refers to this as "getting into bed with" your suppliers or customers or business partners.
So I was interested to read an interview with Prith Banerjee, director of HP Labs (Riding the Recession the HP Way, BBC News, 14 March 2009). Here are some key quotes.
In other words, HP believes the business architecture implemented last year gives it greater viability in the current environment. We shall see if they are right.
Tidd, J. 'Technological Innovation, Organizational Linkages and Strategic Degrees of Freedom', Technology Analysis and Strategic Management 5(3) 1993, pp 273-284
One of the ideas I picked up many years ago from a paper by Professor Joseph Tidd was the strategic importance of this choice: which external relationships are dominant, and how this affects the internal power relationships within the organization.
- For example, a technology breakthrough strategy would be driven by R&D, often in close collaboration with companies that would normally be regarded as competitors.
- By contrast, a strategy of technology fusion would require a much stronger role for production, with close links to suppliers of component technology.
Obviously such business strategies will need to be supported by information systems that communicate across and between organizations in an appropriate manner. Some strategies may require so-called Chinese walls, providing a level of protection from information leaking prematurely to competitors. Some strategies require a degree of proximity bordering on intimacy - business jargon refers to this as "getting into bed with" your suppliers or customers or business partners.
So I was interested to read an interview with Prith Banerjee, director of HP Labs (Riding the Recession the HP Way, BBC News, 14 March 2009). Here are some key quotes.
The world's largest technology company says a major reorganisation of research efforts last year will help it survive the downturn and secure its future. In 2008 HP announced a "groundbreaking" move to align the work done in its labs more closely with business goals. ... While most companies keep their most valuable research projects under wraps, HP has taken a different tack. Everything is out in the open and there is a real emphasis on collaboration with universities, government and other industry players.
In other words, HP believes the business architecture implemented last year gives it greater viability in the current environment. We shall see if they are right.
Tidd, J. 'Technological Innovation, Organizational Linkages and Strategic Degrees of Freedom', Technology Analysis and Strategic Management 5(3) 1993, pp 273-284
Thursday, July 24, 2008
Images of Organization
I completely agree with Neil Ward-Dutton when he argues that Businesses aren't machines, and enterprise architecture can't make them so. There is a fantasy that Enterprise Architects are architecting the enterprise, when they are at best architecting systems of systems to support the enterprise.
The people who are really making structural decisions about the business organization itself are not called enterprise architects, they are called CEOs or COOs or something like that. And you can bet they aren't playing Zachman bingo.
Neil and I agree about a lot of things, but one of the things we disagree about is the word "alignment". (See previous debate on Business-IT Alignment). I think this word completely misrepresents the relationship between IT and business, and I think Neil's argument here just reinforces my opinion on this.
But the image of a business as a machine is a powerful one, not restricted to enterprise architects. Gareth Morgan devotes the second chapter of his modern classic Images of Organization to this metaphor, and to showing the limitations of this bureaucratic view. (Essential reading for enterprise architects.)
The people who are really making structural decisions about the business organization itself are not called enterprise architects, they are called CEOs or COOs or something like that. And you can bet they aren't playing Zachman bingo.
Neil and I agree about a lot of things, but one of the things we disagree about is the word "alignment". (See previous debate on Business-IT Alignment). I think this word completely misrepresents the relationship between IT and business, and I think Neil's argument here just reinforces my opinion on this.
But the image of a business as a machine is a powerful one, not restricted to enterprise architects. Gareth Morgan devotes the second chapter of his modern classic Images of Organization to this metaphor, and to showing the limitations of this bureaucratic view. (Essential reading for enterprise architects.)
Sunday, April 27, 2008
Merging Capability Modeling with Process Modeling
Nick Malik asks about the relationship between capability model and process modelling. "If your company is a process oriented one (or becoming a process oriented one), how do you fit in capability modeling? Do these two methods conflict?"
Nick suggests two answers. In this post I want to offer a third answer. But first we have to understand the purpose of each type of modelling.
Nick mentions two purposes for capability modelling - project planning and service design.
Nick's first answer is that a capability is a top-level chunk of business, while processes are at a lower level. In a later post, Nick says this is how FEA handles capability and process modelling. As Nick acknowledges, FEA actually calls them business areas (or Lines of Business) rather than capabilities. In my 2001 book on the Component-Based Business, I called these things Business Components, and this terminology is still used by IBM in its Component Business Model. I think this is a useful construct, but that's not exactly what I call capability.
Nick's second answer is that a capability corresponds to the objectives of a specific organizational unit. Capabilities are not directly linked to processes; both capabilities and processes use and share atomic-level activities. This is better, but I am uncomfortable with the organizational tie-up.
Meanwhile, the latest version of MODAF does explicitly include "capability" as a first class construct. MODAF includes a hierarchical decomposition of capabilities, and a many-to-many mapping between capabilities and processes (which it calls "operational activities"). This is a lot closer to my notion of capability.
Another way of getting to my notion of capability is to take Nick's second answer and remove all mention of organization units. While the organization structure may give us some important clues about what an organization does and how it does it, I am careful to avoid hard-coding the organization structure into my business models.
So what is the point of modelling capabilities as well as processes? To justify capability modelling, I want to articulate two additional purposes.
The capability defines WHAT the business does; the process defines HOW the business does it (and the organization structure defines WHERE the business does it). So we expect the capability to be more stable than the process; many capabilities should be shareable not only between different processes within a single enterprise, but between multiple enterprises.
This then raises the question of capability modelling techniques - how do we analyse capabilities? We certainly need to map capabilities onto outcomes (as in Nick's second answer) , but we also need to analyse commonalities and variations within and between capabilities, as well as other dependencies between capabilities. In fact the diagram I find most useful, both for planning and for service design, is the capability dependency diagram. MODAF V 1.1 includes a suggested notation for capability dependency diagrams, but I use a slightly different notation.
Nick suggests two answers. In this post I want to offer a third answer. But first we have to understand the purpose of each type of modelling.
Nick mentions two purposes for capability modelling - project planning and service design.
- Project Portfolio Alignment - "With capability modeling, you create a hierarchy of the company's capabilities. You then identify the capabilities that best align to corporate strategy, and which one of them need the most work. Focus your work there, and you get a big payoff through focused investment."
- Service Design - "The activities are where you actually perform automation. You connect services to these activities. This is where work is done."
Nick's first answer is that a capability is a top-level chunk of business, while processes are at a lower level. In a later post, Nick says this is how FEA handles capability and process modelling. As Nick acknowledges, FEA actually calls them business areas (or Lines of Business) rather than capabilities. In my 2001 book on the Component-Based Business, I called these things Business Components, and this terminology is still used by IBM in its Component Business Model. I think this is a useful construct, but that's not exactly what I call capability.
Nick's second answer is that a capability corresponds to the objectives of a specific organizational unit. Capabilities are not directly linked to processes; both capabilities and processes use and share atomic-level activities. This is better, but I am uncomfortable with the organizational tie-up.
Meanwhile, the latest version of MODAF does explicitly include "capability" as a first class construct. MODAF includes a hierarchical decomposition of capabilities, and a many-to-many mapping between capabilities and processes (which it calls "operational activities"). This is a lot closer to my notion of capability.
Another way of getting to my notion of capability is to take Nick's second answer and remove all mention of organization units. While the organization structure may give us some important clues about what an organization does and how it does it, I am careful to avoid hard-coding the organization structure into my business models.
So what is the point of modelling capabilities as well as processes? To justify capability modelling, I want to articulate two additional purposes.
- Management of Variation - Capabilities can often be decomposed into highly generic elements and asset-specific elements. (See my example of Green Coffee Beans.) Decoupling these capabilities helps to drive higher levels of cross-process and cross-organizational sharing.
- Viable System Design - A complete system needs to include management capabilities such as planning and coordination as well as operational capabilities. With a capability model, I find it much easier to check for completeness than with a process model.
The capability defines WHAT the business does; the process defines HOW the business does it (and the organization structure defines WHERE the business does it). So we expect the capability to be more stable than the process; many capabilities should be shareable not only between different processes within a single enterprise, but between multiple enterprises.
This then raises the question of capability modelling techniques - how do we analyse capabilities? We certainly need to map capabilities onto outcomes (as in Nick's second answer) , but we also need to analyse commonalities and variations within and between capabilities, as well as other dependencies between capabilities. In fact the diagram I find most useful, both for planning and for service design, is the capability dependency diagram. MODAF V 1.1 includes a suggested notation for capability dependency diagrams, but I use a slightly different notation.
Sources
- MODAF Version 1.1 (April 2007)
- L. Cherbakov et al, Impact of service orientation at the business level (IBM Systems Journal, 44/4, 2005)
- M. Dodani, The Architecture of Business (JOT 17/4, 2008)
- R. Veryard, Component-Based Business: Plug and Play (Springer, 2001)
- R. Veryard, Capability Dependency (CBDI Journal, May 2007)
Tuesday, July 04, 2006
BPM and SOA 2
Lots of interesting debate about the relationship between BPM and SOA: Phil Gilbert (Lombardi), Jesper Joergensen (BEA), Steve Jones, Mike Rosen (BPTrends, pdf), (via Sandy Kemsley). And loads by Bruce Silver: Phoney War, Still the Exception, Will Deliver. See also Sandy Kemsley's BPM lens.
So what is the relationship between BPM and SOA? In a series of articles entitled "BPM inside the belly of the SOA whale" (1, 2, 3), Colleen Frye of SearchWebServices collects a range of ideas from different experts:
And what about the "Inside the Whale" metaphor used in the title of the articles? This metaphor is commonly associated with George Orwell's essay Inside the Whale, where it was used to denote (and criticize) a disengagement or decoupling between the writer (inside) and the political environment (outside). Salman Rushdie wrote an article called Outside the Whale, which called for a reengagement (alignment, tight coupling) between the writer and the political environment.
The separation between Inside/Outside (or Private/Public) is of course a crucial element of the component/service story. The belly of the whale is a metaphor for encapsulation. In Frye's version, BPM is on the inside and SOA is on the outside. From a business perspective we might have expected this to be the other way around. (There is a story here about business/IT alignment that I have blogged about separately. Update: URL added.)
So I think I can identify two propositions that I think many people would agree with.
Technorati Tags: BPM SOA service-oriented
So what is the relationship between BPM and SOA? In a series of articles entitled "BPM inside the belly of the SOA whale" (1, 2, 3), Colleen Frye of SearchWebServices collects a range of ideas from different experts:
- BPM is putting a business face on SOA
- BPM and SOA as ... two sides of the same coin
- BPM and SOA are ... orthogonal
- BPM sits on top
- BPM is one of the main entry points for the business side of SOA
- BPM ... hand-in-hand with SOA
And what about the "Inside the Whale" metaphor used in the title of the articles? This metaphor is commonly associated with George Orwell's essay Inside the Whale, where it was used to denote (and criticize) a disengagement or decoupling between the writer (inside) and the political environment (outside). Salman Rushdie wrote an article called Outside the Whale, which called for a reengagement (alignment, tight coupling) between the writer and the political environment.
The separation between Inside/Outside (or Private/Public) is of course a crucial element of the component/service story. The belly of the whale is a metaphor for encapsulation. In Frye's version, BPM is on the inside and SOA is on the outside. From a business perspective we might have expected this to be the other way around. (There is a story here about business/IT alignment that I have blogged about separately. Update: URL added.)
So I think I can identify two propositions that I think many people would agree with.
- BPM and SOA are not tightly coupled. It is possible to have BPM without SOA; and it is possible to have SOA without BPM.
- There is synergy between BPM and SOA. There are some potential advantages from combining BPM with SOA, which are not available from BPM alone or SOA alone.
Technorati Tags: BPM SOA service-oriented
Sunday, September 04, 2005
Inscription and Loose Coupling
While searching for something else, I happened upon a dissertation on Business Processes and IT in the Pharmaceutical Industry, by Kai A. Simon. The dissertation contains a lot of useful material, including a comparison between the change management practices of several large consulting houses. (PDF is available via the Waellisch website.)
But what I want to talk about here is a theoretical aspect of loose coupling. Simon derives a theory of loose coupling from Madeleine Akrich's concept of inscription.
But what I want to talk about here is a theoretical aspect of loose coupling. Simon derives a theory of loose coupling from Madeleine Akrich's concept of inscription.
The relation between global and local aspects of an infrastructure can be analyzed through the concept of inscription (Akrich 1992). ... Taking this point of departure, we can describe how inscription occurs at technology and organizational level and what impact it has on the relation between IT and organization.
- Technology inscription can be defined as the rigidity of the technology in constraining the users in the way they are related to the technical object. In other words, it refers to the way technological systems can be used within or outside their design and which forms of work-arounds the system allows or prevents.
- Organizational inscription, on the other hand, reflects the level of freedom or rigidity in organizational procedures or, in other words, the extent to which organizational agents are allowed to reshape the ways in which the technical object are used with respect to organizational rules.
To the extent that technology inscription and organizational inscription are orthogonal, we get a 2x2 matrix.
Here is Simon's account of the four quadrants, including some comments on the implications for BPR and process improvement.
Strict alignment
In this case, the design of organizational procedures leaves no room for local adaptation. At the same time, technology is rigid: There is no option for use outside the defined context. Standardization of technology and organizational procedures and strict alignment between these elements typically characterize the infrastructure.
In most process improvement initiatives, the aim is to develop and implement a strictly aligned organizational and technical infrastructure, following a pre-defined process design and using information systems that are supporting this design efficiently.
Rigid Technology
Organizational procedures are open for local adaptation, while technology does not permit changes in use. Infrastructure is characterized by tensions between global and local organization procedures aiming at satisfying the same objectives, but differing in the means for their achievement.
[Simon describes a change management project that fell into this category, despite the original intention to develop a strictly aligned infrastructure.] The reason can be found in the lack of control that was exercised with regard to process compliance. It was assumed that all monitors would comply with the globally designed process and senior management was not aware of the local adaptations that took place.
Loose coupling
Organizational procedures and technology use can be redefined and adapted locally. The infrastructure allows adaptation to internal and environmental dynamics and is typical of knowledge intensive organizations.
[Simon describes a change management project with this intention, which was discontinued after the organization underwent a merger.]
Rigid organization
In this context, organizational procedures are strictly defined at global level, while technology is open for modifications. The infrastructure is characterized by tensions between different technologies adopted at local level, or local variations in technology use. This context is typical for a post-merger situation, where the merging firms are aiming at developing a common and standardized set of organizational procedures, but maintain their individual technical infrastructures.
As described here, loose coupling gives you THREE different types of flexibility - technological flexibility, organizational flexibility AND flexibility in the relationship between technology and organization.
Reference: AKRICH M., 1992, «The De-scription of Technical Objects» , in BIJKER W., LAW J., (ed.), Shaping Technology/Building Society. Studies in Sociotechnical Change, Cambridge Mass., MIT Press, p.205-224.
UPDATE: I have just received an email from Kai Simon, who writes:
The version of my dissertation you have found on the Waellisch site is not the final one, but a draft that was modified in several aspects before it was published. E.g., the final version does not contain a comparison of four consulting approaches, but only of those that were used in the case study company.
However, the section you analyse has not been changed. You can find the final version in the publication section of my web site (http://www.informatik.gu.se/~kai
The section on inscription and loose coupling is based on the work that I have conducted with Antonio Cordella, one of my colleagues from my time at the Viktoria Institute in Sweden (http://www.viktoria.se). So it was a joined idea and I would like to give Antonio the credits he deserves.
Our concept was the result of our research, but we also received valuable input from the late Claudio Ciborra. He was in the lead for the book "From Control to Drift - The Dynamics of Corporate Information Infrastructures" (Oxford University Press) that summarizes the results of multiple case studies on the manageability of IT infrastructures.
Thanks Kai
Friday, September 03, 2004
Grid versus SOA
Are Grid and SOA compatible? Phil Wainewright thinks not.
Secondly, there may be nothing wrong with an architecture that deploys both tight coupling and loose coupling - provided that the overall geometry makes sense. (As an analogy, think of the bone structure of the human body, which provides both strength and flexibility.)
Phil Wainewright agrees about granularity at least.
SOA aims to create a unified loosely coupled software architecture in which resources can be plugged in and out at will. Grid aims to do much the same in hardware, except that being hardware, most commercial implementations tend to prefer tight coupling wherever possible, because that allows them to squeeze higher performance out of the environment.Firstly, we can agree that SOA has a tendency towards loose coupling and heterogeneity, while much of the current grid work has a tendency towards tight coupling and virtual homogeneity. But this is not an absolute contradiction - merely a tension that has to be watched.
Secondly, there may be nothing wrong with an architecture that deploys both tight coupling and loose coupling - provided that the overall geometry makes sense. (As an analogy, think of the bone structure of the human body, which provides both strength and flexibility.)
- For example, it may make sense to deploy loose coupling within the business and within the software application, in order to achieve tight coupling (known as Alignment) between the business requirements and the application services.
- Conversely, it may make sense (despite Phil's criticism) to deploy tight coupling at the hardware level in order to support loose coupling at the application level.
Phil Wainewright agrees about granularity at least.
"Adopting an SOA can help you realize much greater efficiencies in resource utilization without having to buy any new equipment at all. SOA doesn't need grid - it virtualizes all resources within the IT infrastructure anyway, irrespective of whether they're hardware or software resources. It's just a matter of how granular you want to make your service definitions."I shall say more about stratification and granularity in a future post.
Subscribe to:
Posts (Atom)