| |
| |
|
Adrian Grigoriu
|
zaterdag, 06 maart 2010 |
|
The core of any EA development is the framework, i.e. its meta-architecture. The framework is the glue between components and artifacts. Without a good framework, there is no navigation between artifacts and their components.  Reacties (3)
|
|
meer
|
|
|
zondag, 25 oktober 2009 |
|
EA, ultimately, is becoming, from an IT centric activity, a coordinated set of various activities: IT, BPM, Six Sigma, organization design... Reacties (7) |
|
meer
|
|
|
donderdag, 22 oktober 2009 |
|
Without a framework, we can deliver predictable and repeatable outcomes. An EA framework represents the architecture of the EA, that is the meta-architecture of the Enterprise, i.e. an EA structure with hooks where components fit back in, like the chassis where the car parts mount on.
Schrijf als eerste een reactie |
|
meer
|
|
|
woensdag, 09 september 2009 |
|
To recap, Gartner in translation: the EA governance has to be decentralized, business involved, stakeholders' needs taken care of etc.
That's good stuff. Not sure it helps. Schrijf als eerste een reactie |
|
meer
|
|
|
maandag, 07 september 2009 |
|
Gartner recently identified Ten Enterprise Architecture pitfalls http://www.gartner.com/it/page.jsp?id=1159617
"1. The Wrong Lead Architect: Gartner identified the single biggest EA problem as a chief architect who is an ineffective leader...Gartner recommends that such a lead architect be replaced by someone with strong ‘soft’ skills.
2. Insufficient Stakeholder Understanding and Support
3. Not Engaging the Business People
4. Doing Only Technical Domain-Level Architecture
5. Doing Current-State EA First
6. The EA Group Does Most of the Architecting
7. Not Measuring and Not Communicating the Impact
8. Architecting the ‘Boxes’ Only: Integration and interoperability standards are high EA priorities
9. Not Establishing Effective EA Governance Early
10. Not Spending Enough Time on Communications
The 10 pitfalls are rather common sense, with exceptions but they maybe worth re-iterating.
Obviously, the wrong architects can wreck any undertaking. Soft skills are good as long as there are "hard" skills as well. Involving stakeholders, business is what architects usually do to extract, validate and insure participation etc.
Governance, communications, work in collaboration, team etc.
Nevertheless, it's too easy to blame the Enterprise Architect or the lack of business or stakeholder involvement even if this is the case.
If you look at 10 definitions of EA (http://www.ariscommunity.com/users/koiv/2009-08-20-10-definitions-enterprise-architecture-which-corresponds-yours#comment-1155), none is the quite the same. They point to different aspects of EA. It is either organization, logic, vision, process, discipline, management practice... It's probably all of them.
How would anyone be able to deliver against something that was not properly defined and agreed in the first place? The delivery scope varies widely.
Currently EA is reduced to IT standards, integration and reduction of duplication in IT. How can the promissed benefits be realised?
EA is manned by IT for IT only. Why would other stakeholders bother with it apart from the hefty bill they have to pay only to keep it alive.
An IT architecture describes only spots of an Enterprise where (SW) applications exist. It means nothing to business. An Enterprise is about people, processes, customers and other technologies that are often left out of EA because they are not IT. So there is nothing in it from a business perspective.
Adrian
Adrian Schrijf als eerste een reactie |
|
|
dinsdag, 16 juni 2009 |
|
To what extent an Enterprise Architecture, Strategy or even IT development can be applied to a Group of companies, across geographie or business operations? It is essentially about the determination of the scope of the EA development.
In this blog http://blogs.gartner.com/mark_mcdonald/2009/06/15/is-your-company-an-enterprise-the-answer-matters/#comment-183
Gartner defines a few conditions that make up an Enterprise.
Java Enterprise Edition (JavaEE), Enterprise Applications Integration (EAI) ..., the Enterprise portal thay all refer to the Enterprise. But what is that Enterprise?
Legally an Enterprise (Group) has an identity and a single governance. It is up to the management to define the Group Operating Model (unification..., see Enterprise Architecture as Strategy book). If any. An operating model is the degree of integration and standardisation of various companies within a group. Some companies are part of the financial group but otherwise are left to their own devices. Loosely coupled, I would say, by design.
In IT, the scope of the Enterprise may vary with every IT development.
In the absence of an Operating Model (quite frequent), it is up to an IT group to negotiate with stakeholders the scope of the "Enterprise" for the specific development, if not clearly defined. It depends upon the organisational remit of the IT department, culture, individuals, business requirements...
But legally and financially the Enterprise is still the whole Group.
Schrijf als eerste een reactie |
|
|
woensdag, 27 mei 2009 |
|
I, typically, start with the standard research, interviews and produce what I call a Single Page Architecture, which in fact has nothing to do with IT. It is a synoptic business architecture which everybody loves. Then I try selling it to business, if left to it, since often the relationship between business and IT is not good or is channelled through a single point of contact which becomes the real bottleneck.
Schrijf als eerste een reactie |
|
meer
|
|
|
woensdag, 01 april 2009 |
|
One of the best remarks I had about my EA work is that while I mentioned that an EA picture is worth a thousand words, I haven’t supplied it. Point taken. Instead, I provided a general framework. Stakeholders would not be interested in the debates and subtleties of an EA framework. The framework is for the EA architect to use.
Reacties (1) |
|
meer
|
|
|
woensdag, 28 januari 2009 |
|
The Cloud is, in fact, a business concept even though created by the IT world. But so are SOA and Enterprise Architecture. And it should refer only to the services cloud of your Enterprise. Schrijf als eerste een reactie |
|
meer
|
|
|
zondag, 18 januari 2009 |
|
Enterprise SOA failed for lack of business support, drivers and proper preparation, given the project size and implications. The technology usually associated with SOA (ESB, BPMS, WS) for orchestration, discovery, integration is alive and well. Similarly, SOA at the application and suite levels. Take for instance the trend to design applications suites observing SOA. Reacties (1) |
|
meer
|
|
|
dinsdag, 02 december 2008 |
|
Let me begin with a brief content page of a few next posts on Enterprise Architecture roadblocks, a theme I proposed a while ago.
I. Vague EA definition and scope
II. Uncertain Return Of Investment
III. Diversity and verbosity of EA frameworks, lack of consensus
IV. Design outcomes not fit for purpose
V. Ambiguity and competition with other technologies, SOA, ITIL ERP
VI. Effort governed by IT alone
VII. EA politics
VIII. Flawed Enterprise transformation planning and execution
IX. Improper EA maintenance and failure to employ proper tools
Schrijf als eerste een reactie |
|
meer
|
|
| << Begin < Vorige 1 2 Volgende > Einde >>
| | Resultaten 1 - 11 van 20 |
Via Nova Architectura is not responsible for the content of blogs, but authors and readers are asked to adhere the following guidelines. Authors are strongly encouraged to check facts, cite sources, present
balanced views, acknowledge and correct errors. Respect copyright, fair use and financial disclosure laws. Please do not disparage organizations, or individuals. Being critical of someone's practice is acceptable, when it is done in a professional manner. Prevent usage of marketing statements. Comments should be relevant to the specific post they are attached to. Spam, flaming, personal attacks, and off-topic comments are not
permitted. Readers are requested to notify
Dit e-mail adres is beschermd door spambots, u heeft Javascript nodig om dit onderdeel te kunnen bekijken
of any violations. The editor holds the right to remove any statements that, in the editors opinion, infringe the above guideline(s). The author receives a notification of this action.
|
|
|
