Framework method

> That is made clear in the Structure of the TOGAF
> Document Figure in which business vision and drivers and business
> capabilities are clearly outside of the architecture.

Not exactly outside, George! Rather the other way around... everything else is subsumed within (and follows from) Business Architecture, unless you are building an organisation bottom-up (which is not untrue of many I have seen). See this from TOGAF9:



Best regards,
Joseph

On Apr 27, 2:41 pm, "Pitagorsky George"
wrote:

> I agree that TOGAF centers on the IT, as do mot of the EA initiatives I
> have encountered. That is made clear in the Structure of the TOGAF
> Document Figure in which business vision and drivers and business
> capabilities are clearly outside of the architecture. The figure
> includes a reference to "non-architectural aspects of business
> operations." Even the business architecture piece refers to the
> business architecture as a means to "support an agreed Architecture
> Vision", implying that the business architecture is something outside of
> the architecture itself.

> The integration of all aspects of the enterprise into an architectural
> vision is a logical extension of an architecture approach. It is a
> challenge to make the transition from IT architecture supported by
> business architecture for use in governance and expense control to a
> true enterprise architecture that sets a stage for ongoing process
> optimization. To make that transition, there is need for cultural
> change.

> George Pitagorsky
> Consultant at NYC Dept of Education
> 718 707 4536

> -----Original Message-----
> From: Kevin (PragmaticEA.com) Smith
> Sent: Monday, April 26, 2010 3:51 PM
> Subject: Re: Framework method

> @Andrew Galletly:" Togaf does state that the inputs to the
> Architecture Vision "such as the enterprise mission, vision, strategy,
> and goals - have been documented as part of some wider business
> strategy or enterprise planning activity that has its own lifecycle
> within the enterprise", however, they are still an input and as such
> form the scope of any subsequent architecture work. Is the omission
> of this
> Business Context-type work your rationale for stating Togaf is not an
> EA Framework?"

> Yes. But that's not the only difference/reason why I say TOGAF is not
> an EA framework.

> As soon as you get down to project level work, it's not EA. EA does
> exist at that level but only regarding governance and the
> identification and management of Enterprise Debt.

> EA is much much more about strategic planning and about connecting the
> entire breadth of the enterprise but not the depth. EA (IMHO) is a
> cultural approach.

> You can have a look at how I contrast TOGAF with other EA frameworks
> at
> http://www.pragmaticea.com/display-doc.asp?DocName=peaf-overview1-framework-comparison

> Page 10 gives you a 3 dimensional comparison using 6 axes.

Sustainable Architecture

I particularly liked this from Richard Latham's presentation on Sustainable Enterprise Architecture at The Open Group's 22nd Enterprise Architecture Practitioners Conference:

Framework method

Hmmm... what according to you would be an Enterprise Architecture Framework, Kevin? ;-)

I would agree with Kevin, to a certain extent about TOGAF being dragged down by the weight of its past (and possibly current) IT baggage. Just look at TOGAF 9 Part III Architecture Principles, towards the suggested Business Principles. All the "Business" Principles seem to be about "information management decisions". I would have thought the "information management decisions" would be within the scope of Application Principles or Technology Principles. Architecture Principles are a corner-stone for the whole of the Enterprise decision-making agenda. Not all decision-making is about "information management" alone.

TOGAF9 has made a lot of progress towards focussing on the Enterprise layer, but there is still a lot of ground to be covered, and some to be discarded. You can't be top-heavy and bottom-heavy at the same time. And TOGAF needs to make up its mind where it wants to be - focus on the details at the bottom layers or focus on the decision-making at the upper layers of the enterprise.

Just to clarify, I'm not saying that IT should be completely ignored, as some others seem to be saying. Almost the whole of the enterprise and its operations are IT dependant now. And you simply cannot be making enterprise decisions without understanding the impact on your operations or strategy. IT ignorant decision makers are a key business risk! But, I am very much saying that IT (and anybody else sitting on sidelines) should not be running the enterprise.

Best regards,
Joseph

On Apr 12, 7:14 am, "Kevin (PragmaticEA.com) Smith"

wrote:
> TOGAF is not an Enterprise Architecture Frameowrk.

> TOGAF is an IT Architecture Framework.

System of System

I agree! EA is not just focussed across a single LoB, but spans across all the LoBs. All of the LoBs have something in common which brings them coherently together into an enterprise. Otherwise, they would each be enterprises unto themselves, having nothing in common with any other LoBs. And there would be an argument about divesting or spinning off such LoBs. If EA does not raise its focus higher, there is no benefit derived from being part of an enterprise.

I'm not saying the EA should become an ivory tower and not understand the realities at the ground level. This is most often the fall of EA.

Currently, I am engaged in the intergration of an acquisition. What I am trying is to make any requirement into an enterprise requirement, and realise the benefits of the enterprise capabilities and maximise potential. We do not realise any benefits of being part of a larger entity, if everyone has their own way of doing things. Learn from the differences and use that knowledge to leverage your business capabilities. Going pedantic about rationalisation and making every business/technical processes an exact clone across divergent cultures and jurisdictions, might risk killing your business. There is a fine line in between... We need to provide scope for variances on the frontline, as needed.

Best regards,
Joseph

On Apr 14, 4:26 pm, "wpb...@gmail.com" wrote:

> > Another difference is that EA is about the "enterprise" - typically
> > focussed on a single business, whereas a SoS may cross multiple
> > "enterprises" / organisations and address a wider set of interactions
> > (eg, air traffic management including airlines, radar systems, air
> > traffic controllers, flight planning systems)

> That may be true of the approach of many enterprise architects but, is
> not characteristic of the entire discipline nor of all enterprise
> architects. (Up until recently, I was an EA on a systems engineering
> team at the FAA and I was always mindful of interactions with external
> parties, particularly those represented in the JPDO.) The "enterprise"
> is not a physical/legal entity, rather, it is the entire scope of the
> domain and participants, at hand. And that is pretty much all the
> consideration the definition needs for practical purposes. In this
> case, NextGen was the "enterprise", not just the FAA and not just the
> DoD, etc. As one of the systems engineers mused, EA really isn't
> "enterprise" architecture as much as it is "ecosystem" architecture.