> competitive advantage, to be implemented based on the available resources
> I am differentiating it from the architecture needed to grow business.
Interesting... something to ponder about! Is EA better at being tactical for the short term? Or is EA more suitable at being strategic for the medium to long term? This will probably open up another debate in the forum, if I understand right.
I would ask what is the timeframe EA needs to look at. That would also define what "short" term is. It could differ from a few months to a few days depending on who you talk to. The more tactical issues you get involved with - the farther away you move from the decision makers and the decision making process. I would say leave it to the detailed designers to worry about tactical short term issues. This is not for architecture to get involved in. Don't get me wrong - you can't ignore tactical issues.
You are quite right. The current business dynamics are increasing the rate of flux. And IT can't live in history wanting many moons to deliver something. That was yesterday for yesterday's business climate. Which is history now! We need to be radical, yet prudent. If the head is moving fast forward, the tail can't remain stuck in the ground. One solution does not fit all. Some industries are extremely static. But, if you are in a fast moving industry like finance, your architecture needs to be a cultural fit too. If not, your architecture is a failure, possibly becoming a business liability. That was partly what I meant in my previous post.
Kind regards,
Joseph
On Feb 15, 5:57 pm, Mridul
> Hi Joseph,
> Thanks for the comments.
> I think we need architecture for supporting and stabilizing business. As you
> have mentioned nothing is sustainable in the long run. [with so much
> business dynamics changing every few month]. I have came across
> businesses[like insurance / finance] who have always complained for not able
> to react in time for any change in industry dynamics [environmental change
> or competitor products]. Here an architecture can really help - if it can
> handle these changes.
> I am talking about the changes which need to be seen as to enable short term
> competitive advantage, to be implemented based on the available resources
> I am differentiating it from the architecture needed to grow business.
> On 11 February 2010 22:20, Joseph George < > joseph.geo...@scottish-southern.co.uk> wrote:
> > Mridul,
> > > 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
No comments:
Post a Comment