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:
- Implement SOA Governance or Formalize It
- Staff the right people for the right roles
- SOA Technical Working Group
- SOA Is part of Enterprise Architecture
- Be Agile, Think Agile
- Start Using Collaboration Tools
- Internal Marketing
- Social Gatherings Outside Office
- Sell SOA Benefits to C/D level and Secure Sponsorship
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.
SOA Governance Technical Standard: A very robust although conceptual Governance Framework by the Open Group.
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.
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!
- 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:
- Analyze all of the requirements and ensure that these conform to the expected level of quality.
- Discover and catalog the SOA Assets and ensure that these can be traceable backwards and forwards.
- 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: 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
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/
Distributed Agile Links:
A must read post on this topic by Martin Fowler:
Nice link on a post that outlines lessons learnt on distributed agile:
Jira (best when used with Green hopper): In my opinion one of the best tools for managing scrums:
Rally: I am currently using it at a client project and I think its good.
Scrum Wise: A very intuitive tool I've used.
Excellent blog listing several Agile management tools:
Also look at the Gartner Magic Quadrant: http://www.techostan.com/docs/quadrant.pdf
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:
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.