Downloaded 64 times
Uploaded byZuora, Inc.
Subscribed 2016: SaaS Application Architecture Defined
The document discusses the significance of SaaS application architecture, emphasizing its role in aligning business goals with current technology and team capabilities. It outlines the components of an ideal architecture and the importance of continuous evolution to meet changing inputs. Key takeaways highlight the perspective architecture provides and the necessity of leveraging peer experiences.
More Related Content
Similar to Subscribed 2016: SaaS Application Architecture Defined
More from Zuora, Inc.
Subscribed 2016: SaaS Application Architecture Defined
- 1. SaaS Application Architecture Defined UnveilingSaaS Reference Architectures
- 2. welcome speakers page 02 Susana Castro Business SystemsAnalyst Matthew Rochester Manager Solutions Architecture Tony Dyck IT Director Adam Kessler Solution Architect
- 3. why do weneed architecture? page 03 a well articulated architecture can provide perspective on the effort required to make the past meet the future. perspectiv e
- 4. what is the “ideal”architecture ? page 04 An ideal architecture optimizes an organization’s: 1. business needs / goals 2. current state application 3. core principles 4. team skillset it depends.
- 5. example architecture build “inputs” page 05 01 outline businessgoals Scale order to cash cycle. Consistency. Customer Focus. Maximize Zuora usage 03 define core principles Nine keys. Be your own reference account. Cloud first. Agility. Expect Change 02 analyze system (SWOT) Zuora. Salesforce. Drawloop. DocuSign. Financial Force. NetSuite 04 analyze team (SWOT) Salesforce and Zuora development.
- 6. when is myarchitecture finished? page 06 Set time aside now to revisit your architecture, as the inputs will continually evolve; your architecture needs to evolve alongside these changes. never.
- 7.
- 8.
- 9.
- 10.
- 11. key takeaways page 11 1. Architecture givesperspective 2. Architecture evolves 3. Leverage your peers architecture experience
- 12. Q&A page 012 Susana Castro Business SystemsAnalyst Matthew Rochester Manager Solutions Architecture Tony Dyck IT Director Adam Kessler Solution Architect
- 13. Check out ZuoraAcademy for more great info and actionable advice. All the info you need to build and run an amazing subscription business. https://www.zuora.com/academy/
Editor's Notes
- #2 Today we are going to talk about architecture. We will explore what architecture is and why it is important. We will discuss a process for gathering key information necessary to build your own architecture. And we will hear from 3 distinguished panelists – they will describe the architecture in place at their organization and give color to some of the process that went into defining their architecture. Before we start, let me introduce our panelists:
- #4 If you are in front of one of those big mazes (labyrinth) you can devise a plan to get you out of the current problem. That is not architecture – that is solution design. Architecture is the process of rising up above the maze to get a perspective of the whole landscape ahead à see other obstacles after it (rivers, mountains, ravines), and determining the best path to your goal given your assets, skills and preferences. A client can have business needs to expand their subscription-based business model. Simply implementing a subscription-based billing tool is a project-based solution. Architecture zooms out to look at other parts of the business, applications, teams and core principles, to determine whether there are other factors to consider rather than just “implementing application XYZ”. In our example, the client was already in the mids of replacing its ERP system without understanding the impact a subscription-based billing tool would have on that implementation. Implementing an ERP solution would out looking at the larger landscape would have been short-sighted, solving only part of the problem.
- #5 There is no single architecture that is optimized for everybody. However, we can learn from our peers – what principles they hold high, what needs are they prioritizing, and see how these drive their reference architecture. This can help validate points in our architecture, and give us other ideas of things to include.
- #6 Here are a few examples from the inputs we at Zuora put into our reference architecture. Obviously this is not the detail, but just there to get a few items on the board for you to see. And in case you are not familiar – SWOT stands for Strengths, Weaknesses, Opportunities and Threats. For instance our relationship with Salesforce is a strength, and we have an opportunity (which aligns with a business goal) to increase the use of our own product. I don’t think we had a weakness on the system side (however if you have a brittle, difficult to change legacy system, it would definitely be a weakness). From a system threat perspective, if one of your applications was failing to continually evolve, or be acquired by a competitor, you might consider that a threat.
- #7 Every time your organization adds a feature, buys additional software / licenses, existing software is upgraded, business goals change or you team skillset changes, you need to validate and adjust your architecture. Make it a point to continually track the changes to inputs and set aside regular inputs to evaluate the changes and adjust the architecture accordingly. Your architecture evolves with your business.
- #12 Architecture balances several key inputs that are organization-specific Architecture should constantly evolve as those key inputs change. Review often Leverage your peers architecture experience – especially lessons learned