Tuesday, August 11, 2015

SOA Guiding Principle change

Upcoming Udemy course lecture.



SOA GUIDING PRINCIPLES 


RECOGNIZE THAT SOA
ULTIMATELY DEMANDS CHANGE ON MANY LEVELS







Transcript:



The SOA manifesto
includes this as one of guiding principles right near the top, because SOA is a
strategic initiative and because strategic typically can to demand changes or
many levels in your organization.  It is
highly recommended you create a center of excellent or COE. You want to create
a service factory team, that build these services especially in the beginning
as you start to migrate from traditional software approaches to SOA.  You are going to have a service life cycle,
the service development life cycle is all about building the intrinsically
interoperable both SOA governance.  We
are talking about meta data. We are talking about run time governance.  We are talking about control of strategic and
initiative and goals.  All of those are
changes.

Technology- the
technology includes things like standards, infrastructure, tools, middle ware,
and they may mean significant cost in acquisition and training. 

Organizational changes
- most SOA initiatives mean changes in it but many also include marketing
 and  corporate   governance.
Within new teams such as SOA governance board and the service factory
will cross departmental lines that means resources need to be dedicated from various
department participating.  Some of the
standards: standardized service contracts so that you can have any number
different services you can access some all in the same way because they have a
standards services contract, canonical schema. You want to have single schema
within a services domain because if you do  then you can interoperate
between those services without having to do any data model transformation.  And lastly the standardized software development
life cycle needs to change.   The SOA
strategic initiatives requires additional governance in the software
development life cycle you may already be using.  

So let’s talk about
some examples because SOA is typically an enterprise strategic initiative, it
will involve multiple departments.  That
means that you need to have coordination   conversation and a sense of
goals that all department do and department head must agree to.   Typically larger standardization you have
many commercial off the shelf software applications you buy and those need to
the integrated.   The integration of those
of is facilitated by SOA and therefore the changes that might be necessary
include how to adapt and how to codify the various interfaces that you might need
to access to those commercial off the shelf software. 

You are going to find that
there is resistance to standardization the resistance come from “well it’s
harder to do” or as I heard recently “you mean you want to define a single a
schema that covers of APIs, good luck!”  So it’s not a matter of should you to do it,  it’s a matter of how do you do it and what needs
to be done and you will find there is resistance to that all over the place,
thank you.

No comments:

Post a Comment