Oop 2014 sw architekt v3

1,052 views

Published on

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,052
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
19
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Oop 2014 sw architekt v3

  1. 1. Everything You Always Wanted to Know About Software Architects* but Were Afraid to Ask © 2014, Prof. Dr. Michael Stal
  2. 2. Why do we need Architects? „We use an agile process where architecture is built by community“ „Architecture is being created in one small design step“ „Our application is so small; architecture design is a waste of resources“ „We always use the same reference architecture“ Get rid of the architectural chains and get rid of architects Houdini
  3. 3. Because Architecture is the Backbone of any System Architecture design comprises the whole lifecycle Architects have many responsibilities that are not related to design Almost all design-bycommunity efforts result in bad products (see Frederick P. Brooks‘ The Design of Design) Architecting and implementation need different sets of skills Architectural flaws cause substantial costs and risks (i.e., accidental complexity as opposed to inherent complexity)
  4. 4. Becoming an Architect seems to be incredibly easy Just read the right books ... and obtain some mathematical skills
  5. 5. Just shift your Shape Some Miracle Developer Architect
  6. 6. Birth of Architects In some organizations architects are those who have the label „Architect“ (on their business card)
  7. 7. Birth of Architects (cont‘d) cont‘d) Some other organizations may use sophisticated questionaires
  8. 8. Birth of Architects (cont‘d) cont‘d) Advanced organizations may even have a job profile ... ... that is insufficient (e.g. RUP)
  9. 9. Design errors may cause expensive and lethal failures Architecture as the backbone of all systems: Tacoma Narrows Bridge (1940) collapsed due to neglecting resonance forces Radiation Therapy System Therac-25: lack of quality and software failure caused 3 deaths Architectures with lack of quality are doomed to fail Architecture design should happen in a planned and systematic way, not ad-hoc Skilled & experienced architects needed across the whole product lifecycle, not just in one short project phase
  10. 10. Lousy Architects create lousy Architectures ... Tower of Pisa: structural engineering did not work very well Intempo Skyscaper, Spain: Architects forgot elevators between 21st and 47th level – Maybe for health reasons Airport BER: No compliance with safety regulations led to a very large delay
  11. 11. ... and Lousy Architectures cause Disasters „Even God himself could not sink this ship“ Challenger Disaster caused by bad rocket booster design Ariane 5 explosion due to overflow exception
  12. 12. And all of this reduces Customer Happiness
  13. 13. How can we find good Architects? Only with the help of wizards? Or by chasing this rare species in its habitats? Architects in quest for good design Or by assigning the role to some unfortunate developers? Architecture as the Holy Grail
  14. 14. Architects Habitat - Theory What we want:
  15. 15. Architects Habitat - Practice What we often get:
  16. 16. Failure has many Roots We can‘t forbid failure, but we can enforce learning from failure! Cemetery for past/passed projects
  17. 17. Real Architects need Skills, Knowledge & Experience Requirements Engineering Software Architect
  18. 18. Responsibilities and Involvements of Architects (c) Siemens AG
  19. 19. Architecture & Design Skills Architects need deep knowledge and skills such as: Development Processes Architecture Design and Implementation incl. Scoping, Modelling, Prototyping Architecture Evolution & Improvement Product Line & Platform Engineering Architecture Assessment + CQM Assessment of Internal Architecture Quality System and Application Integration Relevant Technologies, Methods and Tools Relevant Best Practices (e.g., Design Tactics, Patterns & Architecture Styles) Usability & Habitability Project management skills are optional but very useful (e.g. for effort planning)
  20. 20. Knowledge of Business and Strategy To help achieve business goals and make projects succeed it is necessary for architects to know: Business Strategy of own organization Product Roadmap Technology Roadmaps Vendor Management Target Markets & Customers Legal Issues, Patents, Licensing Standards and Regulations (i.e., TÜV, DIN, FDA, …) Product Line & Platform Engineering Otherwise, they cannot make appropriate design decisions
  21. 21. Requirements Engineering Skills Architects must know the domain(s) (i.e. problem domain and solution domain) They need to understand requirements, assess their quality, feasibility & sufficiency, and give feedback Prioritization is typically conducted by business AND architects
  22. 22. Testing & Quality Skills Architects need in-breadth knowledge about Test Plans Test Methods Flavors of testing (integration tests, system tests, component tests, acceptance tests, load tests, …) … and in-depth knowledge about Design for Testability TDD Test Strategies
  23. 23. Soft Skills … are essential for architects, e.g.: Stakeholder-specific communication (Giving and receiving) feedback, Mentoring Listening Conflict resolution Understanding different personalities Leading and convincing others without line function Typically, Architects are leaders without power. Their only means is to convince with arguments
  24. 24. Cooperation, not Confrontation Architecture design requires many contributors: testers, customers, developers, product managers, ... Architecture is the result of joint work Joint work requires close and effective cooperation The day, when the architect died
  25. 25. Domain Knowledge It is important for architects to understand the relevant domains: Solution Domain: important concepts, technologies, methods, tools, trends, ... Problem Domain: Domainspecific concepts, standards, regulations, markets, products, competitors, trends, ... They should know essential aspects in-depth, other aspects in-breadth
  26. 26. Experiences in Software Engineering Architects of small systems should have at least 3 years experience as software engineer experience as a key developer or subsystem architect For mission-critical Systems at least 6 years experience as software/systems engineer 3 years experience as architect in small to medium projects
  27. 27. Uncertainty Principle Architects are facing the Uncertainty Principle in their daily work. They must be able to deal with uncertainty.
  28. 28. Architecture Process Not-iterative, nonincremental development process models don‘t work for strategic and tactical design We require a risk-driven and test-driven feedback loop to address uncertainty Architecture must be built using piecemeal growth even within more „traditional“ processes
  29. 29. Activities of an Architect Architecting does not only involve creation of architectures but also: Monitoring the development process by CQM (Code quality Management) tools Reviewing architectures Improving and extending architectures Conducting Architecture Archeology You need to foster architectures as if they were your children
  30. 30. Unchartered Territories No technology is a panacea – you can even loose all of the benefits by bad design We cannot predict how new and innovative, sometimes disruptive technologies will influence the architecture (e.g. quality attributes) This is even worse for the combination of technologies, and is usually not addressed very well Architects should leverage feasibility prototypes, at least for the most crucial qualities Methods for Architecture Assessment are applicable as well Some Prototypes
  31. 31. Tip of the Iceberg There are many forces architects have to balance E.g., architects are actually facing additional nontechnical and nonarchitectural responsibilities and involvements All the rest Design
  32. 32. Decision Making Architecting is about decision making and risk mitigation Sometimes, architects are anxious to make a wrong decision or don‘t have the courage to enforce a decision Experience tells us to be courageous. In most cases is almost always better to go the wrong way than being stuck Power stealing in India
  33. 33. Essence of Good Collaboration Software Development is a collaborative game [Alistair Cockburn] Thus, communication skills are probably the most important skills in software/system engineering Hence: NO! YES!
  34. 34. Network of Communication Leadership, Communication and Interaction with other roles in software development, are probably the most time-intensive and most important Other responsibilities Roles ? Product line Manager Head of R&D Requirements Engineer Software Project Manager – in a meeting with the CEO Software Developer Test Manager Software Architect
  35. 35. Be aware of Conway‘s Law One important consideration is Conway‘s law: “organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations” Corperate Spam Complex decision processes Meeting Overkill Unclear or overlapping Responsibilities
  36. 36. Systems Engineering In systems engineering the architect needs to closely cooperate with the systems architect Software Architects must understand the contribution of different disciplines (Electronics, Mechatronics, Software, ...) and their „orchestration“, the additional development phases such as commissioning, the pitfalls and traps (developing software when the rest is only partially available, relation of unit costs and software architecture, ...). Electrial Engineering Project Manager Systems engineer Software Architect
  37. 37. Stay Up-To-Date Up-ToTechnologies & methods appear and evolve very frequently Consequently, architects need to stay in sync with relevant technologies and methods „Architect always implements“ Active Networking Mutual Architecture Assessments Attending events such as Conferences Collecting & digesting news in (practioner) magazines, web sites Clouds Sustainability Mobile Devices, ...
  38. 38. The other Side of the Coin Working as an Architect ... can be extremely exhausting, even dangerous.
  39. 39. Ten Reasons not to be an Architect* 1. The gene pool that is your social life will not have a lot of diversity 2. The pay and benefits are not as good as they could be 3. The hours you work are long and under-valued 4. Your ideals don’t really matter 5. If your ideals are important to you, you will lose work 6. Not all architects have fun jobs 7. The systems you use will depress you 8. You will live with terrible decisions 9. Architecture requires a lot of work and dedication 10. You probably won’t be a designer Interestingly this is what building architects think * source: http://www.lifeofanarchitect.com/top-ten-reasons-not-to-be-an-architect/
  40. 40. Avoid Design Hell How to create a bad architect Ingredients: Spaghetti Design Design Erosion Architecture Drift Design Flaw UML Failure, New Requirements ....
  41. 41. If you are still not terrified ... How can you systematically achieve or increase architecture skills?
  42. 42. Let us take the long & dangerous Route to Architect‘s Paradise
  43. 43. Step 1: Profiling Develop a set of skills, knowledge and experience you need as an architect (in your organization) Compare your current profile with this target profile Don‘t do this alone but ask other colleagues and roles to give you feedback about your current profile and their expectations
  44. 44. Step 2: Reflection Elaborate and prioritize your gaps Or as they say in the London Underground: Mind the gap! Make a detailed and prioritized plan how to systematically fill these gaps, e.g. by certifications seminars books, web casts coaches, mentors opportunities to practice ...
  45. 45. Step 3: Doing Perform the aforementioned steps In our fast moving industry this process should be repeated regularly In addition, active networking with other architects is highly recommended
  46. 46. Piecemeal Growth The gaps might be terrifying, but don‘t panic! Be patient and improve step by step, the same way your architectures should be created Your education as an architect will never end, since methods and technologies evolve quickly
  47. 47. Mission Accomplished Be relaxed: You‘ll eventually become a cool architect, ... if you start early enough
  48. 48. Architects Certification Development of company-internal education program Benefits: customized for specific needs continuous improvement not limited to architecture (may also teach in testing, business, …) Liabilities: requires large cost Certification by 3rd party organisations such as iSAQB, IASA, CMU Software Engineering Institute Benefits: usually less expensive Liabilities: more „generic“ to suit all kinds of participants Architecture & Design only different trainings lead to education patchwork Hybrid approach (Best-of-Breed) use option 1, but fill gaps with option 2 (Best-of-Breed)
  49. 49. Example: Example: Siemens Education Programs for (Senior) Architects Introduced in 2007 Main Constituents of Senior Architects Program Proposal of Candidates by Sector CEOs Interviews with each Candidate => Acceptance 4 Workshops with 2-3 month breaks Certification Gates after each workshop Candidates work on topics (optional) and homework (mandatory) within their actual project (no toy projects!) Education areas: Architecture, Business & Strategy, Requirements/Product Line Engineering, Testing & Quality, Soft Skills Network of Siemens Architects who meet regularly and work jointly on important topics So far, excellent feedback and high acceptance in Top Management Content not carved in stone. Feedback of participants helps improve and evolve the material continuously
  50. 50. Learning from Failure
  51. 51. Senior Architect Certification @ Siemens Goal: share good practices, be aware of pitfalls and eliminate the potential for failure in software development at Siemens! © SIEMENS AG
  52. 52. Workshop 1: Establish Architecture Vision © SIEMENS AG
  53. 53. Workshop 2: Realize Architecture © SIEMENS AG
  54. 54. Workshop 3: Sustain Architecture © SIEMENS AG
  55. 55. Don‘t ignore Work Life Balance If you want to be successful, balance work & life This aspect is commonly underestimated In my experience architects with work overload cause more harm than good. Exhausted, unfocused architects are a common root of design flaws
  56. 56. Summary Becoming and being a good architect is a continuous and sometimes hard process, not a one-way street Architects need expertise, skills and knowledge - not only in Engineering but also in Communication, Testing, Requirements Engineering, Business & Strategy, ... Architecting is also about decision making and learning from failure If not reviewed regularly, design flaws will erode the architecture. Thus, Test/Risk-Driven-Design, Architecture Assessments, Refactoring should considered mandatory Reflect continuously about the capabilities you need and where you should increase or improve your knowledge Stairway to Heaven (for Software Architects)
  57. 57. The End Source: starush, flickr.com
  58. 58. Just kidding This is the real Happy End

×