In Zachman's own words, architecture is the thing that bridges business strategy to implementation and architecture begins with the understanding of enterprise and data that constitute information infrustracture. IS must be build on the base of knowledge about enterprise. To do otherwise, IS risks impracticability or bothersome. No single model can describe diverse features of enterprise, multiple models are needed depending on who the model is for and what question the individual want answered. Zachman found three type of individuals (owner, designer, and builder) and three type of questions (what, how, where).
Diverse EA frameworks disagree on perspectives. This is because they are created by different biased minds in different types of organizations/industries. As such they are very picky in finding organizations to be applicable. These frameworks are merely proposed solutions instead of diagnostic tools to tap into the heart of business questions. What I see is that all EA frameworks have business/data architectures. To be diagnostic, EA should start with entperise model (Mintzberg's five in five would be a good theory on this), business architecture, and data architecture. The rest architectures should be based on the needs. The key is the business architecture that drives all other architectures. To have a SO enterprise, we must model business architecture as SO. Jerry --- Alix Cheema <[EMAIL PROTECTED]> wrote: > All, > > > > I've been a registered subscriber to this group for > some time now, > admittedly a 'passive' member until now. However, > based in past and recent > SOA treads, I'm no clearer on what our objectives > are and how we are > supporting them. > > > > The questions, of 'duh, lets define SOA, what is a > service, or how WS > compare to REST, are wearing thin and I can't see > much 'directed' value in > how these topics are helping the group understand, > develop and apply SOA. > > > > So instead of sitting on my arse and say nothing, > I've decided to make a > contribution that will hopefully be of some value to > the group as a whole;- > well, as a minimum it may help clarify or even > extend my thinking. > > > > I'm currently leading an Enterprise Architecture > initiative (based on the > good bits of Zachman and TOGAF) that is using > 'Service Orientation' (SO) as > a central theme. I've intentionally NOT referred to > SOA in the > organisation, because it comes with a lot of > baggage, confusion (its all > about WS, REST etc) and general hatred from the > business. > > > > Our EA programme, focuses on SO across four > different perspectives; > Business, Information, Technology and > Infrastructure. Each perspective > embodies it's own set of services, hierarchy and > value classifications, > among other things. Most importantly SO helps us > achieve traceability > across the EA e.g. how does one type of service (for > example, training > (business service)) relate to another service (for > example, registration > (technical service)) and so forth. > > > > Traceability has helped us measure and identify key > service attribute, e.g. > dependency (coupling), value, goals, drivers and > consumers (including a > whole bunch of other stuff e.g. SLA). > > > > We are using a 'Service Orientated' EA approach, to > help the following > roles execute various tasks:- > > > > - Strategic Planning, can identify the > impact of new business > requirements e.g. change in law, new compliance > reqs. > > - Business Unit Leaders, can identify > services that they can share > and include in their business cases and eventually > deliver within their > projects > > - Enterprise Architects can maintain and > improve a holistic picture > of architecture across the business, helping the CIO > to identify quick win's > and longer term initiatives > > - CIO can maintain a 'service' centric view > of the enterprise > whereby he/she can better allocate funds > > - PMO can start to shape and deliver > service enabled projects > > - Procurement, can push back on suppliers > (and work with them) to > begin delivering more streamlined SO enabled > products. > > - etc > > > > Amongst many business of our initiatives e.g. > outsourcing, technology > refresh, shared services, A Service Orientated > Enterprise approach has > helped us differentiate between core business > services (we build, that > remain with their respective Business Units), ones > to outsource (some one > else builds and runs) or share (centrally funded > capability across Business > Units). > > > > I have not sold SOA into the business, although we > discuss it on a regularly > basis with IT. To the business I sell what a > Service Orientated EA approach > has to offer (as stated above). Finally, SO is not > simply a single model or > approach, it is made up of numerous SO artefacts and > methodologies. E.g. > Service Life-cycle, Service Realisation Methodology > etc. > > > > So, what I'd like to open up with this group is: > > > > - How have you sold SOA, > > - Who are the stakeholders and how do they > use SOA (or its output) > > - What did you have to develop to > design/model SOA > > > > Hopefully this will stimulate an interesting > discussion that may help us all > position and better promote SOA within our > respective organisations. > > > > BTW, we have and have had many IT projects that have > said we are doing SOA. > Although technically valid, the NET value of SOA is > not being appropriately > directed. SOA combined with an Enterprise wide > approach has been our key to > a brighter and more agile enterprise. > > > > Regards, Alix > > > > > > > > From: > [email protected] > [mailto:[EMAIL PROTECTED] > On Behalf Of Jan > Algermissen > Sent: 29 January 2007 09:22 > To: [email protected] > Subject: Re: [service-orientated-architecture] > Definition of SOA - an > offering > > > > > On 25.01.2007, at 17:29, Mark Baker wrote: > > > On 1/24/07, Alex Hoffman <[EMAIL PROTECTED] > <mailto:alex.hoffman%40gmail.com> > wrote: > >> An SOA is simply a software architecture based on > services. > >> What's a service? A software program that is > intended to be used > >> by another program. > > > > Definitions need to be sufficiently precise in > order to enable one to > > distinguish what is from what isn't. > === message truncated === ____________________________________________________________________________________ We won't tell. Get more on shows you hate to love (and love to hate): Yahoo! TV's Guilty Pleasures list. http://tv.yahoo.com/collections/265
