Oop 2014 sw architekt v3

  • 265 views
Uploaded on

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
265
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
7
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Everything You Always Wanted to Know About Software Architects* but Were Afraid to Ask © 2014, Prof. Dr. Michael Stal
  • 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. 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. Becoming an Architect seems to be incredibly easy Just read the right books ... and obtain some mathematical skills
  • 5. Just shift your Shape Some Miracle Developer Architect
  • 6. Birth of Architects In some organizations architects are those who have the label „Architect“ (on their business card)
  • 7. Birth of Architects (cont‘d) cont‘d) Some other organizations may use sophisticated questionaires
  • 8. Birth of Architects (cont‘d) cont‘d) Advanced organizations may even have a job profile ... ... that is insufficient (e.g. RUP)
  • 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. 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. ... 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. And all of this reduces Customer Happiness
  • 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. Architects Habitat - Theory What we want:
  • 15. Architects Habitat - Practice What we often get:
  • 16. Failure has many Roots We can‘t forbid failure, but we can enforce learning from failure! Cemetery for past/passed projects
  • 17. Real Architects need Skills, Knowledge & Experience Requirements Engineering Software Architect
  • 18. Responsibilities and Involvements of Architects (c) Siemens AG
  • 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. 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. 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. 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. 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. 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. 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. 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. Uncertainty Principle Architects are facing the Uncertainty Principle in their daily work. They must be able to deal with uncertainty.
  • 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. The other Side of the Coin Working as an Architect ... can be extremely exhausting, even dangerous.
  • 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. Avoid Design Hell How to create a bad architect Ingredients: Spaghetti Design Design Erosion Architecture Drift Design Flaw UML Failure, New Requirements ....
  • 41. If you are still not terrified ... How can you systematically achieve or increase architecture skills?
  • 42. Let us take the long & dangerous Route to Architect‘s Paradise
  • 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. 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. 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. 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. Mission Accomplished Be relaxed: You‘ll eventually become a cool architect, ... if you start early enough
  • 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. 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. Learning from Failure
  • 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. Workshop 1: Establish Architecture Vision © SIEMENS AG
  • 53. Workshop 2: Realize Architecture © SIEMENS AG
  • 54. Workshop 3: Sustain Architecture © SIEMENS AG
  • 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. 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. The End Source: starush, flickr.com
  • 58. Just kidding This is the real Happy End