> I had for long believed "EA is a continuous process which align IT with
> Business for the purpose of supporting, growing and stabilizing business."
> But have now changed it to "EA is a continuous process which align people,
> processes and technology with Business for the purpose of supporting,
> growing and stabilizing business"\
You don't need architecture for supporting or stabilising business. To keep the lights on, just keep doing more of the same. But that might not be sustainable in the long run. In fact, (dare I say) nothing is sustainable to eternity.
I would agree with the initial part of your statement that "EA is a continuous process", but would end with "to enable the business". Enable for what? To become "agile"! Agile is remaining competitive, or else the organisation goes stale like yesterday's milk left out in the open.
As Adrian says, agile also refers to the business culture, and that is an entirely different ball-game in itself, which architecture can't change on its own. In my experience, architecture reflects the organisational culture. If it's not a match, it won't fit. An agile architecture or an architecture designed for an agile business is not going to stand within a laid-back organisation. This is when skillful leadership in the organisation becomes an asset, and lack-lustre leadership becomes a liability.
Best regards,
Joseph
On Dec 25 2009, 11:21 am, Mridul
> Coming from a IT background, i would like to say. "we do the s/w
> developments using agile methodology in cases where the requirements were
> not clear[i.e creating a new product, something which the team has not done
> before], or doing a research project."
> I would say Agile is way to do work. [anyone can define its own agile
> methodology] and Scrum is a methodology [defined by PM practitioners] which
> is used in s/w development. Using it has its own pros and cons. according to
> the Agile advocates [me too] it is best done by a team. where the team does
> all the work and delivers, the same team is involved till the end of the
> project] the other approach is linear, where different team work in
> different phases. For Architecture, [point me if i am wrong] you need
> different skill set of people who need to identify scope, do process design,
> organize people and functions, do technology designs. The whole TOGAF
> framework which is linear in nature can be easily worked out with a linear
> approach. Also in Agile the deliverable[partial] done at the end of the
> sprint is usable to the client, even if client says no to further
> development.
> To Bring Agility in EA, the methodology need to be defined. These people are
> doing something on Mapping TOGAF to Agile EA.http://agileea.wikidot.com/agile-ea-to-togaf-mapping
> I had for long believed "EA is a continuous process which align IT with
> Business for the purpose of supporting, growing and stabilizing business."
> But have now changed it to "EA is a continuous process which align people,
> processes and technology with Business for the purpose of supporting,
> growing and stabilizing business"\
> Mridul K Singh,
> +919899000152
> Director,
> Thakursahib Tech Consultants.http://www.thakursahib.comhttp://www.linkedin.com/in/mridulksingh
> Enterprise Architecture
> News
> Enterprise Architecture
> Jobs
> 2009/12/25 Rheinlander Kirk
> > You are missing the concept of abstraction - EA is all about abstraction,
> > and if technology is the instantiation of the concept, then so be it. If you
> > think EA is about technology, you are doing it wrong.
> > EA is NOT a design function. It is about coordinating the efforts of a wide
> > variety of engineers, in a variety of disciplines, to execute the strategy.
> > Damn technologists :-) (guilty as charged, but hopefully, grown beyond that
> > narrow point of view!)
> > --Kirk
> > On Dec 24, 2009, at 12:31 PM, joshua sahala wrote:
> > > On Mon, Dec 21, 2009 at 6:48 AM, Rheinlander Kirk
> > wrote:
> > > [cut]
> > >> For that matter, what does technology have to do with enterprise
> > >> architecture?
> > > everything...technology provides the foundation to everything that a
> > > business does.
> > >> Technology is just another of the myriad of elements of the enterprise
> > that
> > >> are part and parcel of enterprise architecture, none more important than
> > any
> > >> other.
> > > if you define technology solely as something that "those people in it
> > > want more money to play with", then, imho, you are ignoring the fact
> > > that everything you do relies upon technology (and possibly
> > > misunderstanding/oversimplifying what technology is).
> > > business cannot exist without technology. from the pen and paper that
> > > people sometimes still use, to the phone systems that customers call,
> > > to the computer that you send your emails from...it is all technology,
> > > and pretty much all of it is necessary for a business to survive
> > > (though i suppose that you could argue a corner case about certain
> > > indigenous populations).
> > > i agree, in part, with your viewpoint that ea has been co-opted by
> > > subsets (silos) of the business organisation. however, it is
> > > disingenous to claim that ea is somehow greater than and/or separate
> > > from the technology that a business relies upon (unless of course you
> > > are sharing your ea deliverables via an oral tradition only).
> > > admittedly my viewpoint is skewed by my background as a technologist,
> > > but, i've seen more than a few companies undermine themselves by
> > > trying to pretend that "business" decisions have no technological
> > > constraints, or by forcing "technology" decisions to be made without
> > > technological understanding (if the business decides to only have a
> > > hammer, then everything *must* be a nail...). just because an ea can
> > > model a business on paper doesn't mean that it is technologically
> > > possible to instantiate that model.
> > >
> > > back to the original question of "can togaf and agile coexist": i
> > > agree with the others whom have said yes; providing that the overall
> > > structure is in place and doesn't unnecessarily constrain the group(s)
> > > that will be using an agile methodology. in other words, understand
> > > agile and build it into the overall business process framework
> > > with regard to the forward-looking nature (or not) of agile: it is a
> > > methodology, and the vision is constrained more by the people involved
> > > than by the method itself. if there is a lack of long-term vision
> > > going in, then it doesn't matter what method is used, it will lack
> > > vision.
> > > regards,
> > > /joshua
> > > --
> > > A common mistake that people make when trying to design something
> > > completely foolproof is to underestimate the ingenuity of complete
> > > fools.
> > > - Douglas Adams -
No comments:
Post a Comment