How to reshape reference architecture

Editor's Notes

• #2: This is the third presentation in a three part series. Why Reshape Reference Architecture What Reference Architecture Models make sense today How to Reshape Reference Architecture
• #3: The first presentation in this series (Why Reshape Reference Architecture) describes why IT must change reference architecture. Important transformative drivers include: The Now Generation Connected Business Demands Complex Requirements The Long Tail Web 3.0 http://blog.cobia.net/cobiacomm/2013/04/25/new-enterprise-drivers/
• #4: The last presentation (What Reference Architecture to Adopt) described: What architectural targets create a more accessible, integrated, collaborative, and adaptive business. What architecture targets create a more Responsive IT team What architectural disciplines enable New IT Delivery What mindset based on composition, decision frameworks, use cases, mentoring, and accelerator packs leads to reference architecture success
• #5: The last presentation (What Reference Architecture to Adopt) provided a few useful reference architecture diagrams Connected Business Architecture Responsive IT Complete Middleware Architecture Ecosystem Platform
• #6: A reference architecture should enable internal and external business service consumers, address future IT strategies, and transition current IT infrastructure and team skill sets. Remember to address business architecture concerns and deliver a business-oriented service platform instead of a technology-oriented framework.
• #7: A common first step is to address integration and data access
• #8: A common second step is to address publishing services and governing the service portoflio
• #9: A common third step is to introduce business process automation and security policy enforcement
• #10: A common fourth step is to introduce business activity monitoring, developer portals, and APIs.
• #11: A sample solution weaving Cloud, services, business processes, identity ,and business activity monitoring is presented in this slide.
• #12: The integration layer allows to : - Integrate anything to anything . Custom transports, formats protocols, and adapters. - Provide a stateful layer for business processes. - Provide a clean layer to access data.
• #13: Use internally to track internal re-use, ease of re-use, control access to cloud services
• #14: Recommend a façade pattern to transform current IT infrastructure into a more secure and managed environment.
• #15: Create an business environment that adapts to competitive events and customer interactions
• #16: Publish and socialize business assets across partners, suppliers, and customers.
• #17: Agile and DevOps principles must be applied across a cross-functional team and the entire lifecycle (e.g. project inception, design, development, deployment, and management). Operations activities related to deployment and release management often hinders agility and time-to-market.   The level of effort required to deploy a real-world application is often non-trivial.  Continuous deployment technology automates operations activities and replaces manual intervention. While dwell time sounds cozy and refreshing, excessive wait states and downtime between activities diminishes team efficiency and engagement.  Automated notifications eliminate dwell time between hand-offs.  Automated project workspace creation, Cloud environment provisioning, and on-demand self-service access reduces wait time between software development phases. A DevOps focus on continuous activity execution (e.g. continuous build, continuous integration, continuous test, continuous delivery) creates a ‘no wait’ environment.   Teams do not have to wait for the next script to run or for the next activity to commence.  By incorporating automation into developer and operations processes, teams bypass time consuming manual tasks and gain faster phase execution.  Both DevOps and PaaS promote simple, on-demand self-service environments that shield team members from complexity and reduce skill hurdles.  By offering on-demand self-service access, rapid business innovation and experimentation is possible. By reducing complexity, team members are not required to obtain special training and skills before consuming IT services and infrastructure. To read more about Enterprise DevOps PaaS accelerating team agility, read a recent blog post.
• #18: Traditional application PaaS (aPaaS) environments do not help organizations build apps, but simply serve as a cloud run-time environment.   DevOps PaaS brings no waits, faster phase execution, widespread accessibility, rapid grassroots innovation, and increased resource availability to IT projects. DevOps PaaS delivers development, test, and production run-time clouds that are integrated into development workspaces containing source code management, defect tracking, requirements management, test automation frameworks, and continuous build.  Figure 2 describes the infrastructure topology underlying a DevOps PaaS. By automating software activities, workflow, and phase approval gates, a DevOps PaaS decreases software development and delivery times.   A rapid IT timeframe closely matching today’s fast business-pace will accelerate revenue growth and enhance customer retention rates.  A New IT model driven by DevOps PaaS will expand development team participation, lower IT cost, and increase business agility. Recommended Reading DevOps Meets ALM in the Cloud PaaS Performance Metrics Multi-tenant, shared container PaaS TCO WSO2 App Factory Product Page
• #19: When building a cloud architecture, consider management, reach, and topology that influences the public versus private decision. Also, consider how you will extend the Cloud PaaS environment to support applications, integration, and APIs.