So%ware Architecture Beyond the Blueprints “Aligning So%ware Architecture with the facets of So%ware Development ‐ Business, Management, Engineering and OrganizaCon” Eldo Architect, Philips Healthcare eldo.issac@philips.com SATURN 2009, North America May 4‐7, PiRsburgh, Pennsylvania, USA • Every So%ware has an architecture. The Facts • Every business dealing with When it comes to so%ware, it’s So%ware has a So%ware not about whether there is an architecture or not, but it’s Architecture EnCty (SAE). more about whether its full potenCal is achieved or not • Like So%ware Architecture, Spectrum of recogniCon of so%ware architecture varies effecCve realizaCon of SAE from ‘everything is code’ to ‘it is the lifeline’ of the organizaCon. varies from instance to Hence the effecCveness/ROI of instance – it depends on architecture varies from situaCon to situaCon. the ecosystem. SEI, SATURN 2009 Architecture Beyond Blueprints 2 1
• Key Tenets of SAE are So,ware Architecture – Architecture and Design En4ty (SAE ) Process – Architect(s ) ‘Body Surface Area’ of architecture goes way beyond – The Architecture the blue prints. There are lot more touch points (impact • EffecCveness of an zones) between SAE and its ecosystem. architecture needs to be measured as the Architecture effecCveness of SAE, not just and Design Process the ‘ility’s of architecture. • This will also help to establish Architect(s) Architecture architecture as a valuable enCty in organizaConal maps. SEI, SATURN 2009 Architecture Beyond Blueprints 3 • The ecosystem consists of – Business SAE’s Ecosystem – Engineering – Management So%ware Architecture is not just an Engineering problem – which – OrganizaCon has been a tradiConal view. • Each of these facets of the Value/success of architecture would depend on SAE ecosystem will have different alignment with all facets of the ecosystem set of expectaCons from architecture and vice versa Business • SAE needs to support and be supported by the ecosystem SAE OrganizaCon Engineering it is living in. It is a two way street to success! Management SEI, SATURN 2009 Architecture Beyond Blueprints 4 2
• If SAE is not aligned with facets of ecosystem Need for aligning SAE with its Ecosystem – It will undermine the ability of SAE to contribute to the Quality of the blue print itself is ecosystem (i.e. ROI). Hence not going to make the architecture or project successful weaken the ecosystem itself. An average architecture that fits – It will undermine the support well for the ecosystem may do architecture needs from the beRer than an excellent architecture that can’t be ecosystem and there by chip supported by the ecosystem. way at the quality and success If posiConed, SAE has many of the architecture itself. qualiCes than can amplify the effecCveness of all facets • Each of the facets of Ecosystem play a role in ecosystem has different constraining the architectural dimensions that affect SAE opCons and deliverables. SEI, SATURN 2009 Architecture Beyond Blueprints 5 Example: SAE and Prod A Prod B Prod C Prod D Organiza4onal Facet ‐ a mutual impact scenario Common Assets Both architecture cartoons are trying to solve the same problem. Common Assets as a This is a common problem in product plaiorm/framework acquisiCons and poriolio management Common Assets as SOA Each model puts different constraints/ expectaCon on organizaConal facet supporCng WS WS WS it ( in addiCon to its impact on other facets and its dimensions) Prod Prod Based on situaCon, a SOA based model may A B WS WS support more distributed development, organizaConal scalability, division of responsibility/ownership, parallel Prod Prod development…etc. This may also come with C D some disadvantage when it comes to low level WS WS leverage points…. ‘but its all about trade offs’ WS WS WS SEI, SATURN 2009 Architecture Beyond Blueprints 6 3
Example: So,ware Development Process impact on SAE So%ware Development Process Architecture Effort (SDP) has great impact on architecture deliverables, effort, effort distribuCon and roadmap. SDPs are very ecosystem specific Some SDP tries to solve arch (major or detailed) earlier where as others push it further down. e.g. when it comes to agile models, refactoring and Time architecCng needs to be coordinated across many sprint Agile teams as it is being implemented Feature Team by the teams. It needs a very Waterfall’ish different way of thinking and organizaConal and management * Data is qualitaCve support. SEI, SATURN 2009 Architecture Beyond Blueprints 7 Agility Vs Planned models ‐ an architecture perspec4ve Mixed models , high variability in Very Agile , high variability , Planned with low 1. Goal: Carry maximum load some phases. Drive bigger and Drive smaller trucks end to variability but reduce variability carried smaller trucks end Drives bigger trucks at anyCme end to end 2. Lesser the variability bigger Variability Flow the truck that can be used Maintenance 3. Increase in variability is compensated by reducing the load and iteraCng more – Release Management / drive smaller trucks. This can Deployment be done at phase levels or end to end. Design, Coding, TesCng 4. Bigger the truck lesser the overhead , i.e. more efficiency 5. Variability in an inner circle is going to force iteraCon in the Architecture outer based on variability flow Requirements Process seIles when : Maximum amount of load is carried most efficiently with raConal amount of variability for the business. Circle of Variability in SDP SEI, SATURN 2009 Architecture Beyond Blueprints 8 4
• The Ecosystem puts constraints/ requirements on the SAE SAE and Ecosystem : – Each facets of the organizaCon Mutual Impact has different dimensions which iniCates these constraints / To be successful, there needs to be a seamless marriage between requirements SAE and the ecosystem. Each of • Also, SAE has constraints/ the constraints /requirements needs to be analyzed and requirements that needs to met addressed by the ecosystem to achieve its Any assumpCon that just having goals. an architect(s) is going to make project successful, irrespecCve • Alignment of these the ecosystem, is not on solid grounding. requirements affects all elements of SAE – Architecture On the flip side, every architecture can’t be supported and design process, architects by every ecosystem. and the architecture – and the First step to success here is to ecosystem understand these touch points between the SAE and its ecosystem SEI, SATURN 2009 Architecture Beyond Blueprints 9 Dimensions of Interest for SAE [1] Business Management Organiza4on Engineering/Requirement Engineering/Architecture Analysis Business Model So%ware Development Team Size Market Maturity and Stability Size Market Maturity Process Team ValidaCon Complexity Project Size Planning DistribuCon Resource Needs Quality ARributes Domain Complexity EsCmaCon OrganizaConal Tools support Cost Quality Needs Risk Management Boundaries Customer InteracCon Model Team Knowledge Customer Involvement CompensaCng for Employee Skill PrioriCzaCon Team Size and DistribuCon & Accessibility deviaCon External Process Availability of Domain DocumentaCon Release Models Predictability and Dependencies ExperCse External Dependencies Delivery Models Reliability of plan OrganizaConal Domain Size Architecture ContribuCon ImplementaCon Business Plan Support Structure Domain Complexity to Other facets Models Roles and Responsibility Business Model Traceability Market and Requirement Upgrade Models Team Structure Team and InteracCon with other facets. Stability InteracCon with other Skills and Resource Needs OrganizaConal Deliverables OrganizaConal Culture facets Training Roles..etc. Roles and Resources (skills, Cme, Business Plan Support Traceability ResponsibiliCes ..etc. money) Risk Management Scope Management..etc. Roles and responsibiliCes Skills and Resource Deliverables..etc. Market/Domain knowledge..etc. SEI, SATURN 2009 Architecture Beyond Blueprints 10 5
Recommend
More recommend
