Expertise

Research

Methodology 

When applying SOA techniques, discipline and due diligence are the key. 

1. Characterize the project business goals
   Business benefits are usually independent of SOA architecture (or any architecture) unless the project is a SOA architecture proof of concept. If not a proof of concept, then make sure that the business case is sound and has management buy-in with a roughed out scope, schedule and budget.  The goals should be measurable in a business/financial language.
    
2. Requirements Analysis
   This is the analysis phase in the UML world; it represents a formal specification of the business goals. Interview the stake holders. Write a detailed requirements document. Construct use cases. Hold a review. Get signoffs. Ultimately the requirements document becomes a contract metaphor between the implementation team  and the business. If all requirements are met, you get paid. 
    
3. Describe how the SOA Architecture meets the business goal
   We like to separate architecture from business goals. Business goals are the ends, architecture is the means. SOA Architecture is a technical strategy for achieving a business goals but is not in itself the end goal.  If an SOA architectural vision is not in place already, document what the SOA is. If the vision is already documented, then describe and re-affirm how that documented vision meets this project's business goals. Agree on platforms, deployment and development environments, toolsets, 3rd party software and technologies.  Many times a one or more Proof of Concept (POC)  prototypes are needed at this point to validate the architecture vision and associated technology choices against the business goals. This stage is similar to the System Design phase in UML terminology with the added benefit of POCs as a risk reductions technique.  OpenWare Technology document templates can be used to assist in this phase. 
    
4. Construct the Project plan
   OpenWare Technologies like to separate (1) project methodology and planning from the (2) architecture and analysis.  The plan (1)  is how the (2) architecture gets built.  Projects philosophy must be agreed upon, e.g. waterfall, rapid iteration, extreme programming,  continuous testing, customer acceptance, etc.. Phasing, staffing, equipment, risk management,  turnover, priority of deliverables, document management tools,  source code management tools, quality methodologies must all be agreed upon, scheduled and execution tracked.
    
5. Implementation
   OpenWare Technologies  implements according to the priorities specified in the project plan using an agile approach to design and delivery. ( Make it work, make it right, make it fast ) Continuous Unit testing with automated builds generated by code checkins ( maven, cruise control) is the recommended technique for maintaining quality and assessing progress at all phases of a project.  OpenWare Technologies recommends formal check-in of unit tests and the implementation of an integration test that performs higher level end-to-end testing than Unit tests.  OpenWare Technologies  recommends regular frequent turnover  of every 3-4 weeks for integration projects and  every 1-2 months for large application projects to system test. This makes for an assembly-line efficiency.  Demonstrations to key stake holders of key functionality or technical capabilities  are recommended to demonstrate progress and get early critical feedback. If needed templates for High Level Design Documentation  based on UML  principles and continuous testing principles are supplied that can be readily filled in by Design Teams. 
    
6. System Testing
   OpenWare Technologies recommends a basic philosophy of automating system tests and spending time within the QA organization early in a project to implement stress testing frameworks, where system test  has fewer deliverables and can devote time to developing durable test frameworks.  OpenWare Technologies recommends staying engaged on a project until at least 60% of system tests as specified by the requirements documents have been run and passed. OpenWare Technologies is ready to assist, expedite and execute the System Testing phase.
    
7. Customer Turnover
   OpenWare Technologies recommends that customer turnover from system test to operations be handled internally by the client as a function of the System Test organization. This effectively provides a means to transfer technology and responsibility to the IT organization.
    
8. 20/20 Analysis
   OpenWare Technologies recommends that a 20/20 (as in hindsight) analysis be performed to evaluate and encapsulate lessons learned within the organization. A formal document is produced whose primary purpose is formalize best practices, procedures and conventions within the organization as a set of ongoing recommendations. The formal document is produced from data collected during the project such as estimates, XPlanner notes, blogs, wikis, etc..