9 Tips for Organizational Maturity in SOA
One of the
greatest challenges to implementing SOA has in fact nothing to do with the intrinsic
complexity behind a SOA technology platform. It is widely recognized that the
real difficulty lies in dealing with people and processes from different parts
of business and aligning them to deliver enterprise wide solutions. This is not
only true in the case of SOA architectures but rather a challenge faced in
systems design in general. As it has been nicely put by Conway’s
law: “organizations
which design systems ... are constrained to produce designs which are copies of
the communication structures of these organizations”.
Following 9 tips
that have helped me bridge organizational silos by improving communications
and collaboration between teams/departments and also by providing visibility
over available assets:
1. Implement SOA
Governance or Formalize It
Governance is about aligning people, processes and
tools and creating an accountability framework so that it is clear who owns "what", and how and when
"what" is done. Create a well-defined SDLC with clear roles and a
clear RACI matrix. Ensure that everyone understand the contributions expected
of them and value they add to the solution(s). If you already have this, then formalize
it by communicating it and making it accessible to everyone (see following
tips).
For further
info you may refer to:
SOA
Practitioners Guide: For me this
is a true gem. Even though it was created 7 years ago, the concepts and
guidelines described in these documents are still applicable.
http://tinyurl.com/SOAPGPart1
http://tinyurl.com/SOAPGPart2
http://tinyurl.com/SOAPGPart3
http://tinyurl.com/SOAPGPart1
http://tinyurl.com/SOAPGPart2
http://tinyurl.com/SOAPGPart3
SOA
Governance Technical Standard: A very
robust although conceptual Governance Framework by the Open Group.
http://www.opengroup.org/soa/source-book/gov/intro.htm
http://www.opengroup.org/soa/source-book/gov/intro.htm
Oracle SOA
Governance Implementation: Based on real
live use cases and many years of experience implementing SOA and SOA Governance,
I wrote this book to share a practical and pragmatic approach to implementing
SOA Governance using the Oracle Governance Suite.
http://www.packtpub.com/oracle-soa-governance-11g-implementation/book
http://www.packtpub.com/oracle-soa-governance-11g-implementation/book
2. Staff the right people
for the right roles
For
example, the role of a SOA Architect should be as much about
integrating people as it is about integrating systems. Dealing with people
from different departments, backgrounds and agendas is a huge challenge and
must never be forgotten. The SOA architect role requires someone that not
only has sound architectural and technological background but also has
charisma, interpersonal skills and can communicate to the business and technical teams
equally. In a nutshell it requires someone that can connect people and is
capable of selling solutions suitable to addressing different point of views
The following
extract from my book describes the different roles and responsibilities’
usually required in a SOA implementation. Ensure you get the right people for
the right role!
Roles in SOA |
·
C-Level executive
sponsors: Although not depicted in the diagram, C-Level
sponsorship (i.e. CIO, CTO) is imperative in any SOA implementation. Having the right level of sponsorship
will ensure that the organizational, behavioral, and cultural changes needed to
implement the governance processes and procedures are embraced by the
enterprise and not ignored.
·
Functional/Business
analyst:
Responsible for producing suitable functional requirements such as functional
design documents, future process model, and/or business rules catalogue. The
functional analyst should, among other things, engage with the business to
ensure that all the functional requirements are well understood and with the
technical and solution architects to ensure that the requirements are presented
in an appropriate format.
·
Enterprise architect: An
enterprise architect is responsible for ensuring that the solution being
delivered by the project not only delivers to the desired business goals and
can be successfully traced back to its original requirements, but also ensuring
that the overall solution aligns to the wider enterprise strategies and
standards.
·
Solution architect: Solution
architects are responsible for producing solution architectures, capturing the
non-functional requirements and also ensuring that the functional requirements
are consistent with the solution as defined in the solution architecture. The
solution architect may also participate and/or influence the definition of
detailed designs, and may as well take part in the approval or rejection of
these documents. Note that this is a well-established role and this text only
aims to provide a brief overview of the role.
·
SOA architect: The SOA
architect is a subject matter expert (SME) in the technologies in context (for
example Oracle SOA Suite 11g) but also understands and practices general
architecture principles. The role of the SOA architect is to:
1.
Analyze all of the requirements and ensure that these conform to the expected level of quality.
2.
Discover and catalog the SOA Assets and
ensure that these can be traceable backwards and forwards.
3.
Provide technical leadership and guidance to
the design and development teams.
·
SOA designer:
Responsible for providing suitable detailed designs that successfully deliver
all of the desired business and technical functionality. The designer is also
responsible for providing further clarification and guidance to the development
teams. An SOA designer will also create the XML assets such as WSDLs and
schemas, and define the unit test scripts that should be executed by the
developer.
·
SOA developer:
Responsible for building and unit testing SOA services. The developer is also
responsible for packaging the code ready for release, and for producing any
relevant documentation that is required to support the deployment of the code
(such as release notes). The SOA developer may partially contribute to the
deployment and monitoring of services.
·
SOA testers: Test
teams are responsible for defining and executing the test scripts to support
different testing stages (for example, system test, system integration test,
user acceptance test, performance test, among others).
·
SOA support
specialist: Responsible for the deployment of SOA services between
different environments and also monitoring of the SOA infrastructure. Once a
service has gone live, the support specialist is also responsible for
performing bug fixes and regression testing on the code.
·
Configuration manager: Owner
and gatekeeper of code packs and releases. This role, among other things,
coordinates and decides which releases can be promoted between environments.
3.
SOA
Technical Working Group
Create a SOA technical working group with key individuals from different
departments and roles (i.e. business analyst, architects, support specialists,
enterprise architects). This group
should get together (perhaps on weekly or monthly basis) with a clear agenda to
talk about topics such as the SOA projects pipeline, challenges and opportunities
The following diagram depicts suggested roles within this group:
SOA Technical Working Group |
·
SOA Technical Working
Group:
Not a single role, but instead a collection of different roles and people that
together have delegated authority and shared accountability for creation of
design-time and runtime governance frameworks, and the enforcement of these
into different phases of a project.
4.
SOA is part
of Enterprise Architecture
Ensure that
SOA has a presence in the Enterprise Architecture group and their meetings. SOA
is a way of doing architecture and SOA is for the business so ensure that SOA
has representatives at the level on which strategic decisions are made.
There is no better way to articulate this than the following image extracted from the following TOGAF page: http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap22.html
There is no better way to articulate this than the following image extracted from the following TOGAF page: http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap22.html
Open Group - Governance |
5.
Be Agile,
Think Agile
Methodologies
such as Scrum promote knowledge sharing and collaboration. For example stand up
meetings like the daily scrum ensure that the information between teams keeps
flowing and everyone is up to date. Another important aspect of agile is to
ensure that people get together face to face for stand up meetings. When face
to face is not possible because for example the team is geographically
distributed, alternatives such as setting up conference calls or video calls can
be used (below are some useful links on this topic).
There is lots of material available online on the topic of Agile,
nevertheless below there is some material that I’ve found useful:
Agile
Manifesto: Good definition on what agile is all about
Agile / Scrum Cheat
Sheets: Below a good cheat sheet from http://complexitymaze.com/2010/06/10/scrum-cheat-sheet/
Scrum Cheat Sheet |
Also:
Distributed Agile
Links:
A must read post on this topic by Martin Fowler:
http://martinfowler.com/articles/agileOffshore.html
http://martinfowler.com/articles/agileOffshore.html
Nice link on a post that outlines lessons learnt on distributed agile:
http://www.ademiller.com/blogs/tech/2008/08/agile-2008-distributed-agile/
http://www.ademiller.com/blogs/tech/2008/08/agile-2008-distributed-agile/
Agile Tools:
Jira (best when used with Green hopper): In my opinion one of the best tools for
managing scrums:
https://www.atlassian.com/software/jira
https://www.atlassian.com/software/jira
Excellent blog listing
several Agile management tools:
http://agilescout.com/best-agile-scrum-tools/
http://agilescout.com/best-agile-scrum-tools/
Also look at the Gartner Magic
Quadrant: http://www.techostan.com/docs/quadrant.pdf
Gartner Magic Quadrant for Application Management Tools |
Some funny links:
A unique scrum review meeting: http://www.youtube.com/watch?v=Q6jMgmPIxmk
6.
Start
Using Collaboration Tools
Ensure that the right tools are in place to promote team collaboration
and also provide visibility over existing assets. For example, creating a shared knowledge portal using Webcenter for example and encouraging and rewarding staff for actively participating and adding content is a great way of letting teams get to know each other and work together.
Use tools such as Oracle Enterprise Repository to provide asset visibility and
enforce its use with the right level of governance in the lifecycle. Other
tools such as Oracle Team Productivity Center can be of great value when
dealing with large development teams.
Some useful
tools:
Oracle
Webcenter Real-Time Collaboration: http://www.oracle.com/technetwork/middleware/wc-real-time-collaboration/overview/index.html
Team Productivity Center: http://www.oracle.com/technetwork/developer-tools/tpc/overview/index.html
Oracle Enterprise Repository: http://www.oracle.com/us/products/middleware/soa/enterprise-repository/overview/index.html
Free and SaaS
Co-op: very clean UI supporting
features such as share status updates, questions, links, and others. http://coopapp.com/
PBworks: Suite of tools including
in-app instant messaging, live notifications of changes to work spaces, live
editing of documents, voice collaboration, wiki, and others. http://pbworks.com/
MemberHub: Group management and
collaboration tool. http://memberhub.com/
7.
Internal
Marketing
Engage your internal media and communications team to send out regular
(but not too regular) communications to promote successful SOA deliveries and
highlight the benefits realized. This is a
quick and cost-effective way to promote SOA initiatives, its benefits and also
get people on board.
I am not an
expert on marketing however after doing some research on this below are some
links I found useful:
10 simple tips for internal marketing: http://www.bestworkplaces.org/wp-content/uploads/2010/10/tentips_for_success.pdf
Tips to make internal marketing sticky http://frog-dog.com/articles/detail/how_to_make_internal_communications_sticky/
8.
Social Gatherings
Outside Office
Getting to
know your team mates outside the office in a non-work related environment truly
helps build team relationships and increase team morale which ultimately leads
to improved cooperation and communication. Managers should fight their corner to
reserve budget that can be spent on monthly or weekly social dinners, drinks or
other events that get people together and talking. The benefits to the business
that can be realized from this in terms of productivity as a result of the improved communications and improved employee
satisfaction will be much greater than the funds spent.
9.
Sell SOA Benefits to C/D level and Secure Sponsorship
Last but by
no means least; ensure that you
have the sponsorship at C or D level. Without sponsorship from the
top and right level of delegated authority, getting the approvals and budget required to accomplish the previously mention tasks will be unlikely.
----------------------------------------------------------
If you have any suggestions please post a comment and I will be more than happy to update this post!
----------------------------------------------------------
Blog by Luis Weir proofread by Jordan Campbell.
----------------------------------------------------------
Blog by Luis Weir proofread by Jordan Campbell.
keep it up
ReplyDelete