Building a SOA roadmap for your enterprise Presented by Sanjeev Batta Architect, Cayzen Technologies
How to build your Roadmap Hire Cayzen Technologies
Search Google
Sit through another SOA Talk
Need for a SOA Roadmap Why do I need SOA ( Top 5 Reasons) – Everyone is doing it – It’s a cool Buzzword – My agency got funded for a SOA Project – It will look good on my resume – Everyone is doing it
Business Alignment Realizing the need for SOA What is the SOA Promise? – Provide business alignment – Enable business agility – Enable technology reuse – Traceable ROI on technology investments
SOA Adaption Curve
Two different kinds of SOA approaches Top Down
Can a SOA architecture that takes forever to plan and implement truly provide business agility ?
Bottom up
Can a SOA architecture that is built using agile and bottom up thinking provide enterprise benefits?
Pragmatic SOA Roadmap Can we build a SOA in an iterative fashion while delivering a balance between short term and long term ROI ?
Components of SOA Organization and Governance Building Blocks [ Platform ] Architecture and Technology Projects and Applications Business Strategy and Process
Fine Tuning Each component (It’s like flying a plane)
Business Strategy SOA enabled business vision Business Process Architecture Future vision and customer perspective Alignment and traceability to business goals – ( See Cayzen presentation on Agile Enterprise)
Pragmatic Business Strategy SOA by Accident No Business Strategy and Focus on Process Technology Driven SOA Sprawl of Web Services No overarching business architecture Pragmatic SOA Business Alignment and Value Defined Overall Business Strategy and Process Defined Details of Processes mapped at Project Level Death by Planning Too much detail at the Business Level Wait till everything is defined. Analysis Paralysis No immediate ROI defined
How to achieve balance in business strategy and process Align Initiatives and projects to organizational goals. Define a clear business vision for each project Step up one to two levels to view how the project fits in overall organization value chain Define business process at the project and possibly few levels above the project Keep the business strategy and process model current once documented. Use effective business modeling and enterprise modeling tools
Governance Organization structure and Dynamics Team Skills Budget and Funding Standard and practices Operational processes and tools Change Management
Pragmatic Governance Just do it mindset No governance or management Web Services = SOA No real reuse Lots of services, very little architecture Tight Coupling Pragmatic Governance Services are built using a well defined but agile plan Governance is provided to make SOA adaption easier not harder Agile but defined Death by Committee Services take too much planning and big and long meetings Governance only providing enforcement, not enablement Too much paperwork makes adaption really hard
How to achieve balance in SOA Governance Treat governance as enabled and create policies that enable reuse. – Reusing existing services should require less approvals Value and refine governance as on ongoing process, not one time enforcement Define best practices, frameworks and samples. Communicate across development teams to enable reuse and collaborative thinking
Platform Services Infrastructure Services – Imaging, Content Management etc Presentation Services Shared Business Services – Outbound Correspondence Enterprise Service Bus Service Registry, Repository
Pragmatic Platform SOA from start No Platform Support for SOA implementation Point to point services Very little reuse Reinventing the wheel Pragmatic Platform Tools are identified at every major maturity level Consistent but agile implementation of tools Focus on real word scenario, not vendor demos Buried under platform Tools become more important than business value Projects are funded and executed around platform not business value Disconnected from reality
How to achieve balance in SOA Platform Identify the real world scenarios and business challenges, then decide the tool – Don’t define the business problem based on tool Make tool choices based on real usage, don’t stock for things that are not needed and are not going to get used Align tools to actual projects and implement those to deliver business needs – There is no better way to demonstrate value Communicate the value of platform to stakeholders and plan for it as part of projects
Architecture and Technology Reference Architecture Security and Identity Interoperability and Technology choices Products and Integration Availability, Scalability, Performance – SLAs Architecture Change Management
Pragmatic Architecture Architecture What ? Lack of Reference Architecture Basic architectural concerns are afterthought Security is the last thing to worry about Spaghetti systems Pragmatic Architecture Architecture is an ongoing process Agile but forward thinking architecture Strategic and Tactical Architecture Markitecture Good for getting funding Too much focus on future and no tactical approach No concrete implementation plan Disconnected from reality
How to achieve balance in Architecture Create a reference architecture that addresses different scenarios faced by real applications – Provide best practices – Provide pre integrated building blocks Keep the architecture an ongoing job – Architecture is only good if implemented Consider and Test Non functional requirements upfront Consider security approaches upfront Communicate the architecture and reference model to enable consistency Create Architecture review checkpoints through the lifecycle of projects
Where to go next? Implement SOA in Your Projects
Project and Applications Existing Applications Legacy Migration and Interfacing Business Applications Infrastructure and Platform Projects
Pragmatic Projects SOA is a Buzzword Deliver something It works Let someone else figure out SOA SOA is failing to deliver business value Pragmatic Projects Balance between short and Long Term business value Enable forward thinking It works and Its SOA Solving world hunger Too big from Budget Risk and Change Management Too risky, fall back to traditional approaches Replace Technologies, not Architecture
How to achieve SOA in Projects Identify what Business value project needs to deliver Identify Reuse from other projects Identify Architectural maturity and components project will help deliver Identify Governance areas projects will achieve or improve Identify Platform components projects will need, add or improve Identify optimum balance between short term (project) and long term (enterprise) goals
PSOA Process Review Align with Business Architecture PlanArchitectImplement Business Application
Questions