Folks, I have been following the discussion to the topic that I originally posted. There are quite a few good and interesting discussion points that have been highlighted and thats very good.
The question in my mind is this --- when there is a collection of people who think alike in this sphere of SOA Governance, why cant we create an actual formal methodology , a formal , well laid out, documented process on how SOA Governance and its various lifecycle phases may be implemented around a Service Lifecyle. With enough thoughts running around, I think we need to formalize it. And honestly, I tend to think that most of the governance work that has been done so far is more in the lines of operational governance and not much thought has been articulated in the areas of strategy, design and implementation. -Tilak --- miko_68 <[EMAIL PROTECTED]> wrote: > Hi Todd and Anne (and everyone), > > SOA Governance truly reflects the connection between > the business side > and the technology side. The subtle thing about it > is of course that > it involves structured and unstructured information, > humans and > machines and a synthesis of business and IT that > hasn't really been > achieved to date. > > I agree with Todd that communication and > documentation are certainly > as key if not more so then tooling... > > Another key point is that the mechanisms for > applying and enforcing > aspects of SOA governance shift as you move along > the service > lifecycle, whether you are focused on design time, > run time or change > time. > > > Best, > Miko Matsumura > VP of Technology Standards, Infravio > > > --- In > [email protected], > "Biske, Todd" > <[EMAIL PROTECTED]> wrote: > > > > Governance is one of my favorite topics. If > someone asked me the > thing that will influence the success of an SOA > initiative the most, > it would be governance. > > > > As someone trying to build out an SOA in a > corporate IT environment, > I agree with Anne's definition 100%. A very easy > way to look at it is > to compare it to a traditional government. A > government has to > legislate, provide infrastructure, maintain > strategic plans, enforce > laws (police force), etc. These are all activities > that an IT > organization must do to govern an SOA. In reality, > these are all > things that an IT organization should have been > doing, regardless of > whether SOA is being done or not. > > > > The same challenges that municipalities face in > their strategic > growth are faced by IT organizations. Urban centers > grew through a > very centralized approach, but have had to become > more and more > decentralized due to suburban sprawl. As rural > communities have > grown, they have had to work more and more with > their neighboring > communities, possibly sharing common infrastructure > and services. The > same is true of IT organizations. The urban center > can be thought of > as the mainframe or legacy systems. Due to the web, > web services, > etc., portions of the legacy logic needs to be > decentralized to meet > the demands of the future. At the same time, silo'd > application > development represents the rural communities. These > applications have > grown, and the world of business processes is > requiring them to work > together seamlessly, rather than through inefficient > handoffs and > redundant processing. > > > > When the first tool came out claiming to provide > "SOA Governance," I > almost laughed out loud, knowing that there is no > tool or technology > that will provide SOA Governance. There are tools > and technologies > that can make governance easier, but ultimately, it > will come down to > process and communication. If the process and > communication isn't > there, the governance won't be either. At the same > time, we can't > govern by process alone. The things being enforced > (i.e. the > legislation) must be documented for all to see. > Herein lies the real > challege with regards to SOA or, more broadly, > applying governance to > IT. SOA is about looking horizontally while others > are looking > vertically. How do you document the rules > associated with making > something an enterprise service versus an > application-specific > service? Yes, we can have rules around WS-I > compliance and naming > conventions, but this often comes down to semantics > and a strategic > vision (i.e. business service blueprint). This is > akin to a business > applying for a business license in a city. There > will be guidelines > for the application that must be followed, but there > is still a > judgement that must be done by a city council as to > whether they want > the business in their city. There may be general > guidelines in the > city master plan, and the opinions of the council > members are exposed > through the political process, but largely, things > will be handled on > a case by case basis by a set of people given the > responsibility for > making those decisions. If you have the wrong > people in place, you > won't be successful. > > > > -tb > > > > -----Original Message----- > > From: Anne Thomas Manes [mailto:[EMAIL PROTECTED] > > Sent: Sunday, November 20, 2005 7:17 AM > > To: > [email protected] > > Subject: Re: [service-orientated-architecture] Re: > SOA Governance work > > > > > > > > I'd love to see further discussion on this topic. > I'd love to hear > from people what governance practices they are > putting into place. > > > > Steve -- you seem to be associating governance > with autonomic > computing, so I feel obliged to reiterate that > governance is not > limited in scope to runtime efforts. Governance > applies to all stages > of service lifecycle -- design, development, > testing, QA, release > engineering, staging, provisioning, operations, > client provisioning, > testing, error tracking, revisions, etc. > > > > Certainly you want to make runtime operations run > as smoothly as > possible and resolve hiccups as autonomically as > possible, but I would > call that SOA management rather than SOA governance. > Back to Gautham's > comment -- WSM products play an enforcement role in > governance, > because they typically enforce a bunch of policies > at service > provisioning time (configuring security for the > service, etc), and > they enforce policies at runtime (authN, authZ, > auditing, etc). But > SOA governance requires a lot more than just policy > enforcers. > Enforcement is the easy part. > > > > Governance is actually more about putting hurdles > in place to verify > compliance than it is about making things go > smoothly. Governance > makes sure that developers don't circumvent the ops > people so that > they can get their app out more quickly. Governance > is about making > sure that apps have been thoroughly tested before > they get deployed. > Governance is about making sure that an app has the > proper security > protections in place. Governance is about making > sure that the next > consumer that gets permission to use a service > doesn't overwhelm the > system and bring down 20 other apps. > > > > Some parts of governance can be automated. Other > parts of governance > can be guided using human workflow. Other parts of > governance === message truncated === __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com ------------------------ Yahoo! Groups Sponsor --------------------~--> Get fast access to your favorite Yahoo! Groups. Make Yahoo! your home page http://us.click.yahoo.com/dpRU5A/wUILAA/yQLSAA/NhFolB/TM --------------------------------------------------------------------~-> Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
