sorted by: recent | see :
popular
Content Tagged with enterprise + architecture
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.
InfoQ: Beyond SOA: A New Enterprise Architecture Framework for Dynamic Business Applications
Beyond SOA: A New Enterprise Architecture Framework for Dynamic Business Applications
RabbitMQ - Open Source Enterprise Messaging
* A complete, conformant and interoperable implementation of the published AMQP specification * Based on a proven platform * Extensive facilities for management, monitoring, control<sep/>
Java
messaging
Enterprise
opensource
architecture
amqp
movetooss
TOGAF
One or two people have asked about the relationship of SOA process to TOGAF ("The Open Group Architecture Framework"). This is an enterprise architecture framework,
I actually wrote an article back in December 2003, outlining some of the challenges faced by TOGAF 8 in embracing SOA.
TOGAF insiders told me then that TOGAF 9 would provide some support for SOA. Four years later and we are still waiting for TOGAF 9. (The current version of TOGAF is 8.1.1.)
However, there are signs that we won't have to wait too much longer. In July 2007, the Open Group published a white paper, outlining plans to embrace SOA within TOGAF. The white paper acknowledges CBDI as a source for these SOA plans, and we hope that the next version of TOGAF will contain a lot of CBDI thinking.
And of course we shall want to repay the compliment. Much of the SOA Process is based on widely used industry approaches, including TOGAF and Zachmann. When the Open Group publishes its guidance on SOA, we shall certainly want to further align the SOA Process with this.
In the meantime, we welcome further discussion about the process implications of SOA and EA in relation to TOGAF or any other EA framework.
Service-Oriented Architecture (SOA) (The Open Group SOA Working Group, July 2007)
The Open Group Architecture Framework (TOGAF) (Wikipedia)
I actually wrote an article back in December 2003, outlining some of the challenges faced by TOGAF 8 in embracing SOA.
TOGAF insiders told me then that TOGAF 9 would provide some support for SOA. Four years later and we are still waiting for TOGAF 9. (The current version of TOGAF is 8.1.1.)
However, there are signs that we won't have to wait too much longer. In July 2007, the Open Group published a white paper, outlining plans to embrace SOA within TOGAF. The white paper acknowledges CBDI as a source for these SOA plans, and we hope that the next version of TOGAF will contain a lot of CBDI thinking.
And of course we shall want to repay the compliment. Much of the SOA Process is based on widely used industry approaches, including TOGAF and Zachmann. When the Open Group publishes its guidance on SOA, we shall certainly want to further align the SOA Process with this.
In the meantime, we welcome further discussion about the process implications of SOA and EA in relation to TOGAF or any other EA framework.
Sources
Service Oriented Architecture Frameworks (CBDI Journal, December 2003)Service-Oriented Architecture (SOA) (The Open Group SOA Working Group, July 2007)
The Open Group Architecture Framework (TOGAF) (Wikipedia)
Information Model Support
I just received a private email with a suggestion to improve the SAE metamodel.
Page 1 | Next >>
