SOA is how the EA has to be organized to achive business agility - this is how I understand the role of SOA and EA. Certainly, the EA should reflect the roadmap for particular enterprise. The things I would like to avoid is separation of SOA into Enterprise, Divicion, my desktop 'soa' which can easily lead to SOA principle being compromised. More concrete, look at the SOA Reference Architecture standard, which is 'work in progress' as of now, and, I hope, you will find wanted EA elements in there. - Michael
Robin <[EMAIL PROTECTED]> wrote: Well well, I think that SOA without EA is like driving a car without a clear destination. You may enjoy the ride of course and I bet lots of people on this list do ;-) I think EA should indicate the target architecture supporting the business strategy and vision. SOA is then a mean to reach this target enterprise architecture and not a goal on its own. Robin --- In [email protected], Michael Poulin <[EMAIL PROTECTED]> wrote: > > I am afraid that SO{alphabet}A will destroy the concept and allow a "flavor" of SOA for compromising the SOA principles on the ground that in a SOxyzA they are not needed. > > I am working primarily with financial Web sites and, in particular, with Web interfaces for internal and external users. According to Adrian's logic, I have to say that I deal with SOBIA where BI stands for Business Interface. > > However, on the basis of `plain' SOA, I was able to explain my business clients that the Web site represents an aggregation of business services that join its business interfaces for business collaborative tasks and that Web page flow simply reflects the flow of business units of work mixed with the User Experience aspects, and that an interaction between Web sites is nothing more than a business process. This allowed me to re-model the Web interface design as a design of collaboration of business interfaces sitting on the top of business services currently represented by web applications (that will be replaces by SOA services in close future). As a result, my business clients started to address business requirements as interface (vs. service) related which simplified our life significantly. Here is no Enterprise things at all. > > So, I see that SOA works if you start with the business model and stop pushing business into IT (enterprise or application) world. Things like "SOEA is more than EA or SOA" scary me a lot. > > - Michael > > > > "grigoriu.adrian" <[EMAIL PROTECTED]> wrote: > SOA alone is misleading if not taken in the context or scope of the > development. After all, it can be applied to any architecture (an > application architecture for instance) and not necessarily to an > Enterprise Architecture (EA). > A note of caution: Enterprise wide IT architecture is often called > Enterprise Architecture. > > I would like to call it SOEA (Service Oriented Enterprise > Architecture), a target EA with an SO style of architecture. > > For most business people, SOA looks like yet another over hyped > technology. SOA may have its roots in a long history of distributed > components architecture, is usually associated to Web Services > technologies and is often proposed by IT. > But in an Enterprise, services may not necessarily be based on IT. In > fact services can be performed by human beings and/or other non-IT > technologies. A service, as in every day life, is an activity > executed by people and/or technology returning value to its consumer, > at a price. > > But at the soul of SOEA, is the business value for the Enterprise. > SOEA is an Enterprise wide Business Process Re-architecting effort > and more, it will require an aligned governance and organization. > > SOEA is more than EA or SOA. > EA development is the process of achieving technology and > organization alignment to business processes, strategy and objectives. > SOA, as a style of business architecture, is adding value by > enabling business service re-use, quality of service & internal usage > monitoring enabling payback mechanisms and service contracts. More > there are other benefits from enabling services provided over the > Web, using Web Services technologies and from making possible on- > demand outsourcing as SaaS. > SOEA must have support from top management and involve business since > it requires process re-engineering, technology alignment and firm re- > organization, in other words SOEA transforms the whole Enterprise. > SOEA must be the focus of your business strategy until your Service > Oriented Enterprise becomes operational, after a few iterations. > Once implemented, SOEA becomes a powerful competitive asset. > > Thanks > Adrian > more on my view on EA and SOA > blog http://blogs.ittoolbox.com/eai/grigoriu > www.trafford.com/06-0421 "An Enterprise Architecture Development > Framework, Business Case and Best Practices" book > > --- In [email protected], "Alix Cheema" > <alix.cheema@> 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 <alex.hoffman@ > > <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. > > > > 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] <mailto:fullfeatured% > 40yahoogroups.com> > > > > > > > > > > > > --------------------------------- > Food fight? Enjoy some healthy debate > in the Yahoo! Answers Food & Drink Q&A. > --------------------------------- Need a quick answer? Get one in minutes from people who know. Ask your question on Yahoo! Answers.
