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"
> > 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.
No comments:
Post a Comment