On 29/01/07, Alix Cheema <[EMAIL PROTECTED]> wrote: > > All, Hello again Alix...
> > > > 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. I'll go with you on REST v WS. But actually defining the bounds of SOA is pretty important otherwise you'll get things like IBM's "Advanced" ESB claiming to be an SOA product. > > > > 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, Pretty much the same way you are talking about. Selling SOA based on its business benefits and I've normally sold "BSA" i.e. Business Service Architecture not "SOA". The key is to show how this approach will give them a clearer understanding of the organisation and IT than they have today. IMO things like Zachman and TOGAF help with ITs understanding of IT but they don't help the business at all as they are pretty complicated beasts. So BSA is the "simple" bit of a massive iceberg, and in the same way as IT doesn't care about how the business actually does new drug research the business shouldn't care about IT implementation of the vision. A key driver here is there are a lot of recent reports that in the next 3-4 years IT will have to be much more business value focused and much less cost focused. So basically if the CIO doesn't know where the business value is then that CIO won't have a job. Two things you need for a roadmap, where you are today and where you want to get to. EA can help you plan the road, but its a business architecture (and paticularly BSA) that will tell you where you need to go. > > - Who are the stakeholders and how do they use SOA (or its output) Senior IT and LOB in the business. They use the BSA and value matrix to have a common understanding of investment and cost cutting areas and as a clear view of "where to get to". If the CEO gets in then fantastic, but day-2-day its about linking LOB with IT. > > - What did you have to develop to design/model SOA 1) A methodology that is simple and business/IT (i.e. picture) focused. Then its a matter of getting the right people together to develop the big picture. Once you have that you can define the roadmap and justify the investment based on the value map, or create the cost savings to create the investment budget. > > > > 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. Lots of people doing SOA are doing (as DanC pointed out recently) the same old stuff with new technology, its not Service Oriented its just old style with WS lipstick on the pig. > > > > 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]> 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. > > Here is a question that could provide a start towards an > architecturally meaningful definition of SOA: > > 1. In what way does SOA constrain components of a networked system? > (When I design a component, what am I allowed to do and what not) > > 2. In what way does SOA constrain data elements of a networked system? > (When I design a data element, what am I allowed to do and what > not) > > (Of course the answers to this must be testable to be meaningful). > > <throwing-the-gauntlet-mode> > My take is that SOA does not have to say anything about 1 or 2 > that is testable. > </throwing-the-gauntlet-mode> > > Cheers, > Jan > > > > > Mark. > > > > > > > > Yahoo! Groups Links > > > > > > [EMAIL PROTECTED] > > > > > > >
