sorted by: recent | see :
popular
Content Tagged with Architecture + Enterprise
SOA World Expo : Enterprise Mashup Services : Ric Smith (ex-Oracle) : Oct 2008
SOA World Expo: Enterprise Mashup Services
Part 1: Real-World SOA or Web 2.0 Novelties?
User:jaimecid: Jaime Cid delicious bookmarks (feed)
soa
Web2.0
Enterprise
Articles
architecture
Enterprise2.0
woa
Service Oriented Enterprise Architecture Framework (SOEAF)
As a member of the Open Group SOA Working Group*, Awel Dico has produced various working papers about incorporating SOA into TOGAF.
In his latest blog posting, he offers a diagram proposing a service oriented enterprise architecture framework (SOEAF).
This diagram focuses on SOA-based solutions, and I guess this is similar to what people sometimes call Service-Oriented Business Applications (SOBA).
This diagram has a fair amount in common with the CBDI Service Architecture and Engineering approach, but there is one important difference. At CBDI, we have long championed a twin-track approach, separating the architecting, provisioning and operation of reusable services from the architecting, provisioning and operation of service-based solutions. I don't know how this kind of twin-track approach could be accommodated in the SOEAF framework.
In his latest blog posting, he offers a diagram proposing a service oriented enterprise architecture framework (SOEAF).
This diagram focuses on SOA-based solutions, and I guess this is similar to what people sometimes call Service-Oriented Business Applications (SOBA).
This diagram has a fair amount in common with the CBDI Service Architecture and Engineering approach, but there is one important difference. At CBDI, we have long championed a twin-track approach, separating the architecting, provisioning and operation of reusable services from the architecting, provisioning and operation of service-based solutions. I don't know how this kind of twin-track approach could be accommodated in the SOEAF framework.
Architecture in practice, Part 6: Why business process management (BPM) is important to an enterprise
Architecture in practice, Part 6: Why business process management (BPM) is important to an enterprise
[from rugi] Architecture in practice, Part 6: Why business process management (BPM) is important to an enterprise
Architecture in practice, Part 6: Why business process management (BPM) is important to an enterprise
User:jeyrb: jey's network's del.icio.us bookmarks
bpm
Enterprise
architecture
por-leer
User:jeyrb
justificacion
Architecture in practice, Part 6: Why business process management (BPM) is important to an enterprise
This installment in the Architecture in practice column focuses on why business process management (BPM) is imperative for both the business and IT. Effective management of business processes is essential for driving business agility in an enterprise. Get an introduction to BPM and its lifecycle phases, and learn how it is complementary to Systems-Oriented Architecture (SOA).
Silo Culture at UBS
Following my note on Silo-Busting, I wanted to discuss a specific example - UBS.
On its website, UBS offers a full range of jargon-compliant banking services to other banks, including "straight-through processing" and a "modular client interface". It also claims that its approach is unique "because we implement this solution with you – and focus on integrating what have traditionally been functional silos". [UBS: Cash Currency Services]
I also found an advert on the UBS website entitled Global Cash Custody: Thinking Outside The Silos (pdf).
But how is this silo-busting reflected in UBS's own organization and business model(s)?
In April 2008, an internal report blamed "silo culture" for poor risk management across the group. In response, UBS merged the Group's Market Risk and Credit Risk functions into a single unit, with responsibility for the monitoring and controlling of the firm's overall risk exposure across credit, market and country risk, as well as performing portfolio analytics on risk evolution at the overall portfolio level. According to Joe Scoby, Group Risk Officer, "These changes are designed to establish a best in class Risk Control team with an overall view of all risks. The creation of an integrated portfolio and concentration risk group will help break down any remaining information silos between the different risk functions." [Reuters, May 2008. See also Risk Australia Spring 2008 and Online Financial News, June 2008]
Or perhaps not. On 12 August 2008, UBS announced that it was stepping away from its integrated model and establishing its investment-banking, wealth-management and asset-management divisions as stand-alone entities [Economist, 14 August 2008]. UBS chairman Peter Kurer said: “Our review has clearly revealed the weaknesses associated with the integrated ‘one firm’ business model. Some of these weaknesses – such as the blurring of the true risk-reward-profile of individual businesses – are the source of substantial risk, as we have seen in the past few months.” In other words, risks result from putting different businesses in a single silo. [Wealth Bulletin, 18 August 2008]
Writing in CIO Magazine, Chris Potts viewed this as raising two important questions for Enterprise Architecture: The Model or the People? [20 August 2008].
I think there are two deeper questions here. Firstly, enterprise architects need to be thinking of a business as a viable sociotechnical system, which means (among other things) that management command-and-control capability must be included. Secondly, this management capability depends on how complexity is distributed across a large organization - the proper balance between differentiation and integration.
It is complete nonsense to imagine a straight choice between differentiation (completely different business model and organizational silo for each business line) and integration (completely uniform one-size-fits-all business model across all business lines). For me, one of the exciting aspects of service-oriented architecture is the degree to which it supports more sophisticated ways of getting the best of both worlds - differentiation AND integration. But this in turn requires a more sophisticated approach to business modelling. Which (sadly) many enterprise architects don't seem to be ready for.
It will be interesting to see how the current UBS experiment with organization structure pans out. This is certainly the sort of initiative that enterprise architecture should be able to contribute to. If anyone has any inside information, on or off the record, I'd be delighted to hear from you.
On its website, UBS offers a full range of jargon-compliant banking services to other banks, including "straight-through processing" and a "modular client interface". It also claims that its approach is unique "because we implement this solution with you – and focus on integrating what have traditionally been functional silos". [UBS: Cash Currency Services]
I also found an advert on the UBS website entitled Global Cash Custody: Thinking Outside The Silos (pdf).
But how is this silo-busting reflected in UBS's own organization and business model(s)?
In April 2008, an internal report blamed "silo culture" for poor risk management across the group. In response, UBS merged the Group's Market Risk and Credit Risk functions into a single unit, with responsibility for the monitoring and controlling of the firm's overall risk exposure across credit, market and country risk, as well as performing portfolio analytics on risk evolution at the overall portfolio level. According to Joe Scoby, Group Risk Officer, "These changes are designed to establish a best in class Risk Control team with an overall view of all risks. The creation of an integrated portfolio and concentration risk group will help break down any remaining information silos between the different risk functions." [Reuters, May 2008. See also Risk Australia Spring 2008 and Online Financial News, June 2008]
Or perhaps not. On 12 August 2008, UBS announced that it was stepping away from its integrated model and establishing its investment-banking, wealth-management and asset-management divisions as stand-alone entities [Economist, 14 August 2008]. UBS chairman Peter Kurer said: “Our review has clearly revealed the weaknesses associated with the integrated ‘one firm’ business model. Some of these weaknesses – such as the blurring of the true risk-reward-profile of individual businesses – are the source of substantial risk, as we have seen in the past few months.” In other words, risks result from putting different businesses in a single silo. [Wealth Bulletin, 18 August 2008]
Writing in CIO Magazine, Chris Potts viewed this as raising two important questions for Enterprise Architecture: The Model or the People? [20 August 2008].
"Firstly, to figure out the balance in our own organizations between having the ‘right' business model, and everyone's collectively ability to manage it. But also, much closer to home, to remind us to strike an appropriate personal balance between modelling our organization's EA, versus influencing the people who manage it in practice and invest in changing it. "
I think there are two deeper questions here. Firstly, enterprise architects need to be thinking of a business as a viable sociotechnical system, which means (among other things) that management command-and-control capability must be included. Secondly, this management capability depends on how complexity is distributed across a large organization - the proper balance between differentiation and integration.
It is complete nonsense to imagine a straight choice between differentiation (completely different business model and organizational silo for each business line) and integration (completely uniform one-size-fits-all business model across all business lines). For me, one of the exciting aspects of service-oriented architecture is the degree to which it supports more sophisticated ways of getting the best of both worlds - differentiation AND integration. But this in turn requires a more sophisticated approach to business modelling. Which (sadly) many enterprise architects don't seem to be ready for.
It will be interesting to see how the current UBS experiment with organization structure pans out. This is certainly the sort of initiative that enterprise architecture should be able to contribute to. If anyone has any inside information, on or off the record, I'd be delighted to hear from you.
UPDM Group
Restart of the UPDM effort after inital draft failed to reach consensus.
Architecture and Architecture Modeling Techniques
There are several techniques that enable software architecture efforts. These techniques include standard modeling languages such as the Unified Modeling Language (UML); frameworks such as the Model-Driven Architecture (MDA) and the Zachman Framework; and software processes such as the Enterprise Unified Process (EUP). In this article I describe each briefly, summarize their strengths and weaknesses, and then discuss how to apply them in an agile manner. My goal is not to present a detailed overview of each technique, each one is worthy of a book in its own right, instead my goal is to make you aware of the technique and to suggest further avenues of investigation if you’re interested.
Documentation
modeling
Enterprise
architecture
model
ea
zachman
Alexander Saar : Blog : Mindquarry : walking the way - startup, business & life
Mindquarry was founded by three ambitious students of the Hasso Plattner Institute, Potsdam: Alexander Klimetschek, Alexander Saar, Lars Trieloff
User:jaimecid: Jaime Cid delicious bookmarks (feed)
collaboration
Enterprise
opensource
blogs
architecture
startup
businessmodel
Dion Hinchcliffe : ZDNet.com : The WOA story emerges as better outcomes sought for SOA | Enterprise Web 2.0 : Sep 2008
Over the summer the enterprise IT blogosphere was swept up in a conversation around the concepts that many are calling Web-Oriented Architecture, or WOA. A different way to think about service-oriented architecture.
User:jaimecid: Jaime Cid delicious bookmarks (feed)
soa
Enterprise
Articles
architecture
Enterprise2.0
woa
User:jaimecid
Enterprise Architect - Joke or Joker?
What exactly is the joke?
Jeff Schneider: Why Enterprise Architecture is a Joke- Zachman is stagnant
- Poor architecture skills
- Silo organizations with silo funding
- Tooling sucks
- Unconnected models
- People in command make bad decisions.
- The industry has spawned enough new activities to get worried about to justify a whole job role to cover it and make sure it is done.
- EA is not all about Zachmann
- Enterprise architecture doesn't lack tools at all, and in fact has too many
- Funding should never look like enterprise architecture
- James seems content with the state of his Visio and Powerpoint tooling
- The funding model should align with your business strategy
- EAs are security guards with flashlight and no gun
If you put "Enterprise Architecture" and "Joke" into an internet search engine, you find a post from 2005 by one James McGovern: Government Enterprise Architecture is a big fat joke!
- Someone in the government believes that enterprise architecture is all about creating comprehensive documentation. I guess they forgot the part that the most important thing is to add value to the business.
- If you want an actionable enterprise architecture, you must go beyond artifacts.
- Disconnect between EA Governance and IT Leadership ... IT Management often trumps EA Governance to 'get the thing in' ... EAs need to educate IT management, delivery and operations teams on the value of enterprise architecture ... and ... EAs must listen to the needs of their constituents.
- EA isn't defined well enough to model and operate a successful EA organization.
And who is the joker?
In my experience, enterprise architects range from enterprising to unenterprising, from leading to following, from creative to bureaucratic, from essential via useful to downright waste of space.This is not just a matter of intellect and experience, but personal style. One way of characterizing styles is by using the metaphor of the planets, as I did in my post on Mars, Venus, Saturn or Uranus.
- ITIL is from Saturn, which is the planet of governance.
- SOA is from Uranus, which is the planet of innovation.
- The IT budget is from Jupiter, which is the planet of investment.
- Transformation, power and personal mastery.
- The need to cooperate and share.
- Pluto governs big business and wealth, mining, surgery and detective work, and any enterprise which involves digging under the surface to bring the truth to light.
EA Joke or Joker 2
I hope I made it clear in my previous post Enterprise Architect - Joke or Joker that I am not attacking all enterprise architects, or the concept of enterprise architecture (EA). I think there are many excellent practitioners of enterprise architecture, as well as some who don't deserve the job title at all.
In his latest post It's 2008: Is Enterprise Architecture Still a Joke?, James McGovern wants to talk about the value of EA, and I agree this is an important question. I think part of the reason why people sometimes see EA as a joke is because of the large gap between the potential value - what EA could theoretically be achieving in an ideal world - and the actual delivered value. In many organizations the actual delivered value of EA is disappointingly low. (James himself thought this was true of US Government in 2005; the title of his latest post hints that things may have gotten better).
There is not a single explanation for the disappointing results of EA in some organizations. Sometimes it is because the enterprise architects themselves aren't very good at the job; sometimes it is because the larger organization is resistant to some of the opportunities. Jeff Schneider's original post Why Enterprise Architecture is a Joke suggested some additional contributory causes.
Stafford Beer introduced the concept of POSIWID - the purpose of a system is what it does. Never mind what EA ought to be doing, if many enterprise architects are merely playing Framework Bingo, then many people will assume that to be the de facto purpose of EA.
Are people still playing Framework Bingo? Brenda Michelson suggests a quick poll: What does your enterprise architecture group deliver? (Go direct to poll)
James argues that the goal of EA is to improve the quality of the IT ecosystem. Following something like the Goal-Question-Metric paradigm, this leads to specific measures via a set of questions. Here are some example questions extracted from James's post.
Of course similar questions apply to the architecture of buildings. Unfortunately, architects are sometimes more highly regarded for producing something that looks good in the architectural magazines, than for producing something that the client actually wants, or something that will evolve well.
The architects of past centuries whose buildings and names survive are not necessarily the ones who had the greatest ability, but those with reasonable ability who were fortunate in having the most supportive clients. Likewise, the most evidently successful enterprise architects will be those who are fortunate enough to be working in the most sympathetic and supportive organizations. But the enterprise architects who perhaps really deserve our praise are those who are working against the odds, achieving small victories in unsympathetic organizations.
In his latest post It's 2008: Is Enterprise Architecture Still a Joke?, James McGovern wants to talk about the value of EA, and I agree this is an important question. I think part of the reason why people sometimes see EA as a joke is because of the large gap between the potential value - what EA could theoretically be achieving in an ideal world - and the actual delivered value. In many organizations the actual delivered value of EA is disappointingly low. (James himself thought this was true of US Government in 2005; the title of his latest post hints that things may have gotten better).
There is not a single explanation for the disappointing results of EA in some organizations. Sometimes it is because the enterprise architects themselves aren't very good at the job; sometimes it is because the larger organization is resistant to some of the opportunities. Jeff Schneider's original post Why Enterprise Architecture is a Joke suggested some additional contributory causes.
Stafford Beer introduced the concept of POSIWID - the purpose of a system is what it does. Never mind what EA ought to be doing, if many enterprise architects are merely playing Framework Bingo, then many people will assume that to be the de facto purpose of EA.
Are people still playing Framework Bingo? Brenda Michelson suggests a quick poll: What does your enterprise architecture group deliver? (Go direct to poll)
- Standards and policies?
- Reference architecture?
- Proof of concept?
- Reference implementations?
- Business solutions?
- Forums or communities?
- Other?
James argues that the goal of EA is to improve the quality of the IT ecosystem. Following something like the Goal-Question-Metric paradigm, this leads to specific measures via a set of questions. Here are some example questions extracted from James's post.
- Does federated identity enable better security for your business partners?
- What is the quality of source code within the enterprise?
- Is the enterprise architect participating in user group meetings that help propel the ecosystem forward? Are we working for interoperability across the industry?
- How well managed is the enterprise spend? How much money is being spent on compliance? Is this strategic investment being leveraged for other purposes?
Of course similar questions apply to the architecture of buildings. Unfortunately, architects are sometimes more highly regarded for producing something that looks good in the architectural magazines, than for producing something that the client actually wants, or something that will evolve well.
The architects of past centuries whose buildings and names survive are not necessarily the ones who had the greatest ability, but those with reasonable ability who were fortunate in having the most supportive clients. Likewise, the most evidently successful enterprise architects will be those who are fortunate enough to be working in the most sympathetic and supportive organizations. But the enterprise architects who perhaps really deserve our praise are those who are working against the odds, achieving small victories in unsympathetic organizations.
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.)
Dion Hinchcliffe : What Is WOA? It's The Future of Service-Oriented Architecture (SOA)
What Is WOA? It's The Future of Service-Oriented Architecture (SOA)
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.)
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 show 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 show the limitations of this bureaucratic view. (Essential reading for enterprise architects.)
MODAF Version 1.2
A new version of MODAF has just appeared, which puts MODAF firmly ahead of other enterprise architecture frameworks in terms of its support for SOA.
MODAF is the enterprise architecture framework produced by the UK ministry of defence. Version 1.1, which appeared last year, contained a Strategic View, described in terms of Capabilities and Capability Dependencies. Version 1.2 now contains a Service (or "Service-Orientated") View, driven by the Strategic (Capability) View, and sitting above the Systems View.
http://www.modaf.org.uk/
This clearly goes further than the latest version of DoDAF (a roughly similar framework produced by the US Department of Defense), which has a single view for Systems and Services, and no Strategic View.
Meanwhile TOGAF remains stuck in a time-warp. In December 2003, when I wrote an article on Enterprise Architecture for the CBDI Journal, I was told that TOGAF 9, which would have some support for SOA, was "coming soon". Nearly five years later and it is still "coming soon". Soumen Chatterjee expects that "too many players" will produce a "mixed-up world".
There are a few bloggers talking about possible SOA support within TOGAF, including Raj Ajora and Awel Dico, and some good ideas coming out of the SOA Working Group within the Open Group. But they've got some catching up to do.
MODAF is the enterprise architecture framework produced by the UK ministry of defence. Version 1.1, which appeared last year, contained a Strategic View, described in terms of Capabilities and Capability Dependencies. Version 1.2 now contains a Service (or "Service-Orientated") View, driven by the Strategic (Capability) View, and sitting above the Systems View.
http://www.modaf.org.uk/
This clearly goes further than the latest version of DoDAF (a roughly similar framework produced by the US Department of Defense), which has a single view for Systems and Services, and no Strategic View.
Meanwhile TOGAF remains stuck in a time-warp. In December 2003, when I wrote an article on Enterprise Architecture for the CBDI Journal, I was told that TOGAF 9, which would have some support for SOA, was "coming soon". Nearly five years later and it is still "coming soon". Soumen Chatterjee expects that "too many players" will produce a "mixed-up world".
There are a few bloggers talking about possible SOA support within TOGAF, including Raj Ajora and Awel Dico, and some good ideas coming out of the SOA Working Group within the Open Group. But they've got some catching up to do.
soa
Enterprise
architecture
enterprise_architecture
modaf
togaf
cbdi
The Power of Enterprise Architecture
Язык для описания архитектуры предприятия
Is There a Place for OSGi in Enterprise Application Development? (Part 2) | Javalobby
Modularity is a deceptive problem. One would think that this age old requirement would have been cracked a long time ago. In non-trivial, yet relatively simple applications, achieving modularity is not difficult.
Development
J2EE
Spring
Java
Enterprise
Tutorial
architecture
EA Joke or Joker 2
I hope I made it clear in my previous post Enterprise Architect - Joke or Joker that I am not attacking all enterprise architects, or the concept of enterprise architecture (EA). I think there are many excellent practitioners of enterprise architecture, as well as some who don't deserve the job title at all.
In his latest post It's 2008: Is Enterprise Architecture Still a Joke?, James McGovern wants to talk about the value of EA, and I agree this is an important question. I think part of the reason why people sometimes see EA as a joke is because of the large gap between the potential value - what EA could theoretically be achieving in an ideal world - and the actual delivered value. In many organizations the actual delivered value of EA is disappointingly low. (James himself thought this was true of US Government in 2005; the title of his latest post hints that things may have gotten better).
There is not a single explanation for the disappointing results of EA in some organizations. Sometimes it is because the enterprise architects themselves aren't very good at the job; sometimes it is because the larger organization is resistant to some of the opportunities. Jeff Schneider's original post Why Enterprise Architecture is a Joke suggested some additional contributory causes.
Stafford Beer introduced the concept of POSIWID - the purpose of a system is what it does. Never mind what EA ought to be doing, if many enterprise architects are merely playing Framework Bingo, then many people will assume that to be the de facto purpose of EA.
Are people still playing Framework Bingo? Brenda Michelson suggests a quick poll: What does your enterprise architecture group deliver? (Go direct to poll)
James argues that the goal of EA is to improve the quality of the IT ecosystem. Following something like the Goal-Question-Metric paradigm, this leads to specific measures via a set of questions. Here are some example questions extracted from James's post.
Of course similar questions apply to the architecture of buildings. Unfortunately, architects are sometimes more highly regarded for producing something that looks good in the architectural magazines, than for producing something that the client actually wants, or something that will evolve well.
The architects of past centuries whose buildings and names survive are not necessarily the ones who had the greatest ability, but those with reasonable ability who were fortunate in having the most supportive clients. Likewise, the most evidently successful enterprise architects will be those who are fortunate enough to be working in the most sympathetic and supportive organizations. But the enterprise architects who perhaps really deserve our praise are those who are working against the odds, achieving small victories in unsympathetic organizations.
In his latest post It's 2008: Is Enterprise Architecture Still a Joke?, James McGovern wants to talk about the value of EA, and I agree this is an important question. I think part of the reason why people sometimes see EA as a joke is because of the large gap between the potential value - what EA could theoretically be achieving in an ideal world - and the actual delivered value. In many organizations the actual delivered value of EA is disappointingly low. (James himself thought this was true of US Government in 2005; the title of his latest post hints that things may have gotten better).
There is not a single explanation for the disappointing results of EA in some organizations. Sometimes it is because the enterprise architects themselves aren't very good at the job; sometimes it is because the larger organization is resistant to some of the opportunities. Jeff Schneider's original post Why Enterprise Architecture is a Joke suggested some additional contributory causes.
Stafford Beer introduced the concept of POSIWID - the purpose of a system is what it does. Never mind what EA ought to be doing, if many enterprise architects are merely playing Framework Bingo, then many people will assume that to be the de facto purpose of EA.
Are people still playing Framework Bingo? Brenda Michelson suggests a quick poll: What does your enterprise architecture group deliver? (Go direct to poll)
- Standards and policies?
- Reference architecture?
- Proof of concept?
- Reference implementations?
- Business solutions?
- Forums or communities?
- Other?
James argues that the goal of EA is to improve the quality of the IT ecosystem. Following something like the Goal-Question-Metric paradigm, this leads to specific measures via a set of questions. Here are some example questions extracted from James's post.
- Does federated identity enable better security for your business partners?
- What is the quality of source code within the enterprise?
- Is the enterprise architect participating in user group meetings that help propel the ecosystem forward? Are we working for interoperability across the industry?
- How well managed is the enterprise spend? How much money is being spent on compliance? Is this strategic investment being leveraged for other purposes?
Of course similar questions apply to the architecture of buildings. Unfortunately, architects are sometimes more highly regarded for producing something that looks good in the architectural magazines, than for producing something that the client actually wants, or something that will evolve well.
The architects of past centuries whose buildings and names survive are not necessarily the ones who had the greatest ability, but those with reasonable ability who were fortunate in having the most supportive clients. Likewise, the most evidently successful enterprise architects will be those who are fortunate enough to be working in the most sympathetic and supportive organizations. But the enterprise architects who perhaps really deserve our praise are those who are working against the odds, achieving small victories in unsympathetic organizations.
Enterprise Architect - Joke or Joker?
What exactly is the joke?
Jeff Schneider: Why Enterprise Architecture is a Joke- Zachman is stagnant
- Poor architecture skills
- Silo organizations with silo funding
- Tooling sucks
- Unconnected models
- People in command make bad decisions.
- The industry has spawned enough new activities to get worried about to justify a whole job role to cover it and make sure it is done.
- EA is not all about Zachmann
- Enterprise architecture doesn't lack tools at all, and in fact has too many
- Funding should never look like enterprise architecture
- James seems content with the state of his Visio and Powerpoint tooling
- The funding model should align with your business strategy
- EAs are security guards with flashlight and no gun
If you put "Enterprise Architecture" and "Joke" into an internet search engine, you find a post from 2005 by one James McGovern: Government Enterprise Architecture is a big fat joke!
- Someone in the government believes that enterprise architecture is all about creating comprehensive documentation. I guess they forgot the part that the most important thing is to add value to the business.
- If you want an actionable enterprise architecture, you must go beyond artifacts.
- Disconnect between EA Governance and IT Leadership ... IT Management often trumps EA Governance to 'get the thing in' ... EAs need to educate IT management, delivery and operations teams on the value of enterprise architecture ... and ... EAs must listen to the needs of their constituents.
- EA isn't defined well enough to model and operate a successful EA organization.
And who is the joker?
In my experience, enterprise architects range from enterprising to unenterprising, from leading to following, from creative to bureaucratic, from essential via useful to downright waste of space.This is not just a matter of intellect and experience, but personal style. One way of characterizing styles is by using the metaphor of the planets, as I did in my post on Mars, Venus, Saturn or Uranus.
- ITIL is from Saturn, which is the planet of governance.
- SOA is from Uranus, which is the planet of innovation.
- The IT budget is from Jupiter, which is the planet of investment.
- Transformation, power and personal mastery.
- The need to cooperate and share.
- Pluto governs big business and wealth, mining, surgery and detective work, and any enterprise which involves digging under the surface to bring the truth to light.
Page 1 | Next >>
