This document discusses the role and responsibilities of software architects. It begins by explaining why architects are needed, as architecture is the backbone of any system and architectural flaws can cause substantial costs and risks. It then discusses the skills, knowledge, and experience required of architects, such as expertise in development processes, architecture design, requirements engineering, testing and quality, relevant technologies and methods, soft skills, and domain knowledge. The document also notes that architects must continuously learn and improve their skills. It emphasizes that architecture design should be an iterative process to address uncertainty. Finally, it stresses the importance of collaboration, communication, and balancing work and life for architects.
O'Reilly Webcast: Ten Things Every Software Architect Should KnowO'Reilly Media
This is the slide deck used in Richard Monson-Haefel's webcast "10 Things Every Software Architect Should Know." Richard is the editor of the O'Reilly book, "97 Things Every Software Architect Should Know." Presentation give live on 2-17-09/
Architectural Thinking - What Is Architecture?ingo
The document discusses the concept of architecture in the context of company information systems. It defines architecture as comprising processes, function points and applications, data structures and containers, and technological infrastructure. The role of the architect is to arrange these components to establish and maintain the system based on the business models and requirements, though the specific technologies may change over time. Good architecture balances the needs of various stakeholders and follows recognized architectural styles. Architecture is concerned with high-level structural decisions that impact a system's long-term evolution and quality attributes.
This is a slideshow I put together for a Career Day presentation on Architects. I'm planning on recording the audio of the presentation and post to youtube. The timeframe was for 45-50 minutes.
Doing Architecture with Agile Teams IASA UK Summit 2013Chris F Carroll
This document discusses how software architecture can work with agile teams. It addresses methodological questions around how agile scales for enterprises, where architecture fits in the agile lifecycle, and how to address governance, risk, adoption and maturity concerns. Personal questions are discussed around how architects can effectively work with agile teams and add value. Technical questions cover defining agility as a quality attribute and what an agile architecture might look like. The document provides perspectives on these issues from experts in agile and architecture.
The document discusses developing architects through capability-based training programs. It notes that the demand for architects exceeds supply, and in-house training has been ineffective. It advocates defining capabilities that architects should demonstrate, such as preparing architecture documents. It also recommends experience-based programs that impart knowledge, provide mentorship and assess capabilities through activities, exercises and projects. The goal is to align training with business needs and develop architects through a structured, outcomes-focused approach.
O'Reilly Webcast: Ten Things Every Software Architect Should KnowO'Reilly Media
This is the slide deck used in Richard Monson-Haefel's webcast "10 Things Every Software Architect Should Know." Richard is the editor of the O'Reilly book, "97 Things Every Software Architect Should Know." Presentation give live on 2-17-09/
Architectural Thinking - What Is Architecture?ingo
The document discusses the concept of architecture in the context of company information systems. It defines architecture as comprising processes, function points and applications, data structures and containers, and technological infrastructure. The role of the architect is to arrange these components to establish and maintain the system based on the business models and requirements, though the specific technologies may change over time. Good architecture balances the needs of various stakeholders and follows recognized architectural styles. Architecture is concerned with high-level structural decisions that impact a system's long-term evolution and quality attributes.
This is a slideshow I put together for a Career Day presentation on Architects. I'm planning on recording the audio of the presentation and post to youtube. The timeframe was for 45-50 minutes.
Doing Architecture with Agile Teams IASA UK Summit 2013Chris F Carroll
This document discusses how software architecture can work with agile teams. It addresses methodological questions around how agile scales for enterprises, where architecture fits in the agile lifecycle, and how to address governance, risk, adoption and maturity concerns. Personal questions are discussed around how architects can effectively work with agile teams and add value. Technical questions cover defining agility as a quality attribute and what an agile architecture might look like. The document provides perspectives on these issues from experts in agile and architecture.
The document discusses developing architects through capability-based training programs. It notes that the demand for architects exceeds supply, and in-house training has been ineffective. It advocates defining capabilities that architects should demonstrate, such as preparing architecture documents. It also recommends experience-based programs that impart knowledge, provide mentorship and assess capabilities through activities, exercises and projects. The goal is to align training with business needs and develop architects through a structured, outcomes-focused approach.
This document provides an overview of engineering design and the engineering design process. It discusses what design is, the importance of the engineering design process, and describes the typical phases of the design process including conceptual design, embodiment design, and detail design. The document also covers considerations for a good design such as achieving performance requirements, life-cycle issues, and social/regulatory issues. Additionally, it discusses the impact of computer-aided engineering and the importance of designing to codes and standards. The document concludes with a section on societal considerations in engineering design.
The document outlines key concepts in engineering design. It discusses the course objectives which aim to develop an understanding of product design and development through interdisciplinary projects. Engineering design is defined as the creative application of scientific knowledge to solving problems. The design process involves gathering information, generating alternative solutions, evaluating alternatives through analysis and decision making, and communicating results. Different types of design such as original, adaptive, and redesign are also described.
Technical debt in a software system not only impacts the productivity of the team but also compromises the external product quality. Technical debt needs to be managed pragmatically to ensure discipline, value, and quality.
This document provides an introduction to engineering design. It begins by asking foundational questions about what engineering and engineering design are, and the differences between engineering analysis and design. Engineering design is defined as the process of devising a system to meet desired needs, and involves problem definition, research, conceptual design, evaluation and testing. The document outlines the typical steps in the engineering design process, including establishing objectives, generating concepts, analysis, testing prototypes, and improving the design. It also discusses types of designs, issues to consider like ethics and economics, and differences between engineering and other fields like science and art.
- Many software projects fail to be completed on time and on budget due to unrealistic deadlines, poor estimation of tasks, and changing requirements. Architectural flaws and lack of domain knowledge also contribute to project failures.
- Common problems include inadequate testing, poor code quality, lack of documentation, and developers not wanting to work on code they did not write themselves. Traditional software engineering practices have not changed much over the past 30 years.
- A better approach focuses on rapid feedback through small iterative releases, collaboration with customers, responding flexibly to change, and empowering self-organizing teams. Continuous integration and testing also help catch problems early.
The chief technology officer (CTO) is the executive responsible for overseeing an organization's technological needs, research and development. As CTO, they assess short and long term tech needs, make investment decisions, and ensure technology supports business goals. A CTO leads technology teams, makes decisions around product architecture and platforms, and stays on top of new tech innovations. Key skills for a CTO include the ability to motivate employees, solve problems, and communicate a clear technological vision to various stakeholders. There are different types of CTO roles within startups, including technical leads who focus on architecture and development, operational leads who manage implementation, and product owners who have a vision for their product.
An architect makes blueprints and plans for new buildings, deciding if existing structures should be renovated or demolished. They meet with clients to discuss building ideas. Architects work for individuals, companies, or the government, designing all types of structures. It typically takes a year from initial planning until a building's completion. To become an architect requires a bachelor's degree in architecture and the career has experienced 15-16% growth in recent years.
Computer Architecture is still a less well understood discipline within the IT industry. Some still wonder the importance of it and what the benefit of it is. The key to the definition of an architecture are the principles. Here we explore What Is Architecture, What Architectural Styles exist and the 12 Principles of Architecture.
This document provides a template for a project post mortem report to record lessons learned from completed projects. The template includes sections for report details, project parameters, performance including accomplishments and problems, lessons learned, and approval. It is intended to inform future project teams of obstacles, challenges, successes and ways to improve aspects like planning, resources, scope, scheduling and more.
The document discusses using the engineering design process to organize participation in BEST robotics competitions. It provides an overview of the engineering design process, including defining problems, conceptualizing solutions, preliminary design, making design decisions, and detailed design. Questions are emphasized as important tools for properly defining a design problem at each step of the process. Examples of tools that can help structure the engineering design process, such as attribute lists and pairwise comparison charts, are also presented.
This document contains lecture notes from Chapter 4 on concepts in engineering design. It discusses key concepts around products, including definitions of products, the product life cycle which includes stages of introduction, growth, maturity and decline. It also discusses identifying customer needs through methods like interviews, focus groups and observation. The goal is to understand customer needs in order to design products that meet those needs.
Contextually-Driven System Architecture ReviewsTechWell
This document summarizes a presentation about contextually-driven system architecture reviews. The presentation discusses what architecture is, how it exists at the intersection of management, technology, and design. It also discusses problem statements and how they provide important context for reviews by outlining critical success criteria. The methodology of contextually-driven reviews is then outlined, including preparation, the review meeting, and follow-up steps. Benefits include identifying risks early and potential cost and schedule savings. Drawbacks include risks if the client is out of touch and the method's dependency on expertise and face-to-face meetings.
1) The document discusses using systems modeling approaches in engineering to improve understanding and problem solving across complex projects. It focuses on applying these principles to mission critical systems like space applications.
2) Systems engineering and modeling can help address challenges like technical complexity that cause projects to go over budget and late. Model-based systems engineering (MBSE) provides benefits over document-centric approaches by creating a shared living model.
3) Creativity is important for problem solving, and requires thinking across boundaries between disciplines. Technical leadership requires skills like dealing with complexity, decision making under uncertainty, and motivating teams.
This keynote was presented by Rebecca Wirfs-Brock at Explore DDD 2017.
The ouroboros (οὐροβόρος in the original Greek) is an image or archetype of a serpent shaped into a circle, clinging to or devouring its own tail in an endless cycle of self-destruction, self-creation, and self-renewal. Becoming a good software designer sometimes feels like that.
Over time, we build up our personal toolkit of design heuristics. To grow as designers, we need to do more than simply design and implement working software. We need to examine and reflect on our work, put our own spin on the advice of experts, and continue to learn better ways of designing.
The document provides an overview of engineering design and the systematic design process. It defines engineering design according to ABET as meeting desired needs through a decision-making process applying science and engineering principles. The document then discusses the importance and challenges of design, introduces systematic design processes, and outlines typical steps in the design process including establishing requirements, developing product and solution concepts, embodiment design, and analysis.
The software architecture team is responsible for defining and maintaining the software architecture. The team should include architects with a balanced set of skills in both the problem domain and software development. The role and authority of the architecture team needs to be clearly defined to avoid pitfalls like lack of authority, isolation from the rest of the project team, or imbalanced skills among team members.
This document discusses an introduction to software architecture lecture. It covers:
1) The course logistics including assessments, textbooks, and origins of software architecture from addressing issues in other domains.
2) "Accidental difficulties" that have been overcome through advances like programming languages and "essential difficulties" that remain like complexity, conformity, changeability and intangibility.
3) Examples of software architectural styles like the World Wide Web and pipe and filter architectures.
This document provides an overview of engineering design and the engineering design process. It discusses what design is, the importance of the engineering design process, and describes the typical phases of the design process including conceptual design, embodiment design, and detail design. The document also covers considerations for a good design such as achieving performance requirements, life-cycle issues, and social/regulatory issues. Additionally, it discusses the impact of computer-aided engineering and the importance of designing to codes and standards. The document concludes with a section on societal considerations in engineering design.
The document outlines key concepts in engineering design. It discusses the course objectives which aim to develop an understanding of product design and development through interdisciplinary projects. Engineering design is defined as the creative application of scientific knowledge to solving problems. The design process involves gathering information, generating alternative solutions, evaluating alternatives through analysis and decision making, and communicating results. Different types of design such as original, adaptive, and redesign are also described.
Technical debt in a software system not only impacts the productivity of the team but also compromises the external product quality. Technical debt needs to be managed pragmatically to ensure discipline, value, and quality.
This document provides an introduction to engineering design. It begins by asking foundational questions about what engineering and engineering design are, and the differences between engineering analysis and design. Engineering design is defined as the process of devising a system to meet desired needs, and involves problem definition, research, conceptual design, evaluation and testing. The document outlines the typical steps in the engineering design process, including establishing objectives, generating concepts, analysis, testing prototypes, and improving the design. It also discusses types of designs, issues to consider like ethics and economics, and differences between engineering and other fields like science and art.
- Many software projects fail to be completed on time and on budget due to unrealistic deadlines, poor estimation of tasks, and changing requirements. Architectural flaws and lack of domain knowledge also contribute to project failures.
- Common problems include inadequate testing, poor code quality, lack of documentation, and developers not wanting to work on code they did not write themselves. Traditional software engineering practices have not changed much over the past 30 years.
- A better approach focuses on rapid feedback through small iterative releases, collaboration with customers, responding flexibly to change, and empowering self-organizing teams. Continuous integration and testing also help catch problems early.
The chief technology officer (CTO) is the executive responsible for overseeing an organization's technological needs, research and development. As CTO, they assess short and long term tech needs, make investment decisions, and ensure technology supports business goals. A CTO leads technology teams, makes decisions around product architecture and platforms, and stays on top of new tech innovations. Key skills for a CTO include the ability to motivate employees, solve problems, and communicate a clear technological vision to various stakeholders. There are different types of CTO roles within startups, including technical leads who focus on architecture and development, operational leads who manage implementation, and product owners who have a vision for their product.
An architect makes blueprints and plans for new buildings, deciding if existing structures should be renovated or demolished. They meet with clients to discuss building ideas. Architects work for individuals, companies, or the government, designing all types of structures. It typically takes a year from initial planning until a building's completion. To become an architect requires a bachelor's degree in architecture and the career has experienced 15-16% growth in recent years.
Computer Architecture is still a less well understood discipline within the IT industry. Some still wonder the importance of it and what the benefit of it is. The key to the definition of an architecture are the principles. Here we explore What Is Architecture, What Architectural Styles exist and the 12 Principles of Architecture.
This document provides a template for a project post mortem report to record lessons learned from completed projects. The template includes sections for report details, project parameters, performance including accomplishments and problems, lessons learned, and approval. It is intended to inform future project teams of obstacles, challenges, successes and ways to improve aspects like planning, resources, scope, scheduling and more.
The document discusses using the engineering design process to organize participation in BEST robotics competitions. It provides an overview of the engineering design process, including defining problems, conceptualizing solutions, preliminary design, making design decisions, and detailed design. Questions are emphasized as important tools for properly defining a design problem at each step of the process. Examples of tools that can help structure the engineering design process, such as attribute lists and pairwise comparison charts, are also presented.
This document contains lecture notes from Chapter 4 on concepts in engineering design. It discusses key concepts around products, including definitions of products, the product life cycle which includes stages of introduction, growth, maturity and decline. It also discusses identifying customer needs through methods like interviews, focus groups and observation. The goal is to understand customer needs in order to design products that meet those needs.
Contextually-Driven System Architecture ReviewsTechWell
This document summarizes a presentation about contextually-driven system architecture reviews. The presentation discusses what architecture is, how it exists at the intersection of management, technology, and design. It also discusses problem statements and how they provide important context for reviews by outlining critical success criteria. The methodology of contextually-driven reviews is then outlined, including preparation, the review meeting, and follow-up steps. Benefits include identifying risks early and potential cost and schedule savings. Drawbacks include risks if the client is out of touch and the method's dependency on expertise and face-to-face meetings.
1) The document discusses using systems modeling approaches in engineering to improve understanding and problem solving across complex projects. It focuses on applying these principles to mission critical systems like space applications.
2) Systems engineering and modeling can help address challenges like technical complexity that cause projects to go over budget and late. Model-based systems engineering (MBSE) provides benefits over document-centric approaches by creating a shared living model.
3) Creativity is important for problem solving, and requires thinking across boundaries between disciplines. Technical leadership requires skills like dealing with complexity, decision making under uncertainty, and motivating teams.
This keynote was presented by Rebecca Wirfs-Brock at Explore DDD 2017.
The ouroboros (οὐροβόρος in the original Greek) is an image or archetype of a serpent shaped into a circle, clinging to or devouring its own tail in an endless cycle of self-destruction, self-creation, and self-renewal. Becoming a good software designer sometimes feels like that.
Over time, we build up our personal toolkit of design heuristics. To grow as designers, we need to do more than simply design and implement working software. We need to examine and reflect on our work, put our own spin on the advice of experts, and continue to learn better ways of designing.
The document provides an overview of engineering design and the systematic design process. It defines engineering design according to ABET as meeting desired needs through a decision-making process applying science and engineering principles. The document then discusses the importance and challenges of design, introduces systematic design processes, and outlines typical steps in the design process including establishing requirements, developing product and solution concepts, embodiment design, and analysis.
The software architecture team is responsible for defining and maintaining the software architecture. The team should include architects with a balanced set of skills in both the problem domain and software development. The role and authority of the architecture team needs to be clearly defined to avoid pitfalls like lack of authority, isolation from the rest of the project team, or imbalanced skills among team members.
This document discusses an introduction to software architecture lecture. It covers:
1) The course logistics including assessments, textbooks, and origins of software architecture from addressing issues in other domains.
2) "Accidental difficulties" that have been overcome through advances like programming languages and "essential difficulties" that remain like complexity, conformity, changeability and intangibility.
3) Examples of software architectural styles like the World Wide Web and pipe and filter architectures.
The document discusses how much attention should be paid to software architecture design. It argues that architecture is important because it acts as the skeleton of the system and influences all its attributes. While not everything requires upfront architectural design, it is important to deliberately address risks. The right amount of architectural effort depends on identifying and prioritizing risks through techniques like risk-driven design. Architectural choices should aim to reduce risks while balancing tradeoffs. It is also important to embed architectural intent into the code to keep models and implementation in sync.
The document discusses some of the origins and challenges of software engineering. It describes Brooks' classification of software difficulties as either accidental, which have solutions that can be discovered, or essential, which can only have partial solutions or none at all. Examples of essential difficulties include complexity, conformity to changing requirements, and the intangible nature of software. The document advocates that software architecture is key to addressing these difficulties and outlines some similarities and limitations between software and building architecture.
1) The document discusses an agile approach to architecture in software development that focuses on individuals, interactions, working software, and responding to change over rigid processes and comprehensive documentation.
2) It argues that treating architecture as a role filled by few rather than a shared perspective can be dangerous, and that agile principles like small cross-functional teams, test-driven development, and value-driven prioritization allow architecture to help manage complexity and risks.
3) Applying agile concepts to architecture can help teams deliver value early while reducing risks and avoiding overengineering.
This document provides an overview of a course on software design and architecture. The course aims to introduce principles of good software design and architectural techniques. It covers topics like software design processes, architectural styles, object-oriented design, design patterns, and component-based design. The course is divided into two modules - the first covers software architecture and styles, and the second focuses on detailed design using object-oriented principles and design patterns.
The document discusses a roundtable on Solution Architecture training and CITA-A certification. It provides an overview of the training modules which cover topics like business technology strategy, solution architecture, lifecycles, success metrics, stakeholders, and describing solutions. The training aims to help participants understand the solution architect role and gain skills across software, infrastructure, information, and business domains. It also discusses how solution architects balance conflicting priorities and connect with other architects in an organization.
The document discusses several key points about software architecture:
1. Every application has an architecture and at least one architect. Architecture is not just a phase of development but foundational to software design.
2. Requirements analysis and design must be considered together. Existing architectures provide context for requirements and help assess feasibility.
3. The implementation phase aims to faithfully represent the architectural design in code. Deviations from the architecture can undermine its benefits.
4. Architecture centric development sustains focus on the architectural model through all phases from requirements to evolution. This helps manage quality and complexity over the system's lifetime.
The document discusses the role of the modern software architect. It provides definitions of a software architect as someone who makes high-level design choices and dictates technical standards. The main responsibilities of an architect are to limit development choices by choosing standards and frameworks and communicating designs to developers. The document also discusses how the role of the architect changes with the size of the organization and types of architectures like enterprise, solution, and application architects. It notes challenges with more agile development where architecture may not receive focus and issues like technical debt can increase over time.
Developing High Performing Architecture Teams sallybean
Slidedeck for a workshop delivered at the EAC Europe conference in 2016, about how to develop an effective architecture function within an organisation, focusing on the need for soft skills
This document provides an introduction to software architecture. It discusses how software engineers have long employed architectures without realizing it and how architecture addresses issues identified by researchers. It differentiates between accidental difficulties that have been solved through advances like programming languages and essential difficulties like complexity, conformity, changeability and intangibility that cannot be fully solved. It uses an analogy to building architecture to illustrate key parallels and roles. Examples of the World Wide Web and Unix architectures are provided to demonstrate architecture in action.
This document introduces the concept of software architecture and discusses its origins and importance. It describes some of the unique difficulties of software engineering, including complexity, conformity, changeability, and intangibility. It argues that software architecture can help address these difficulties by providing intellectual control, conceptual integrity, and a basis for knowledge reuse. The document uses examples like the World Wide Web and product line architectures to illustrate how architectural design influences software properties and facilitates reuse.
Architectural Engagement Through the Project LifecycleDaljit Banger
Some insight into the work of the Architecture Community for Project/Programme Managers - Presented on 23rd November 2022 at the BCS PMSG - (Video available on YouTube BCS Channel)
The document discusses the role of software architects and how to become one. It describes how architects make important design decisions regarding what to build, how to build it, and how to scale solutions. Architects are categorized into roles like solutions architects, technical architects, and infrastructure architects based on their areas of focus. The document advises learning fundamentals, gaining experience through practice and open source contributions, developing skills in multiple technologies, and becoming a leader and innovator to become a successful architect.
Með tilkomu agile hugbúnaðargerðar er hætt á að forritarar fórni hlutum sem voru sjálfsagðir í aðferðum eins og Waterfall og RUP en eiga fullt erindi í agile þó svo með öðrum hætti. Má nefna skjölun, en margir misskildu agile á þann veg að ekkert þarf að skjala. Skjölun er nauðsynleg þótt hún sé með örðum hætti, en svo er einnig með architecture. Í agile er nauðsynlegt að huga vel að architecture en einnig að átta sig hvað það er sem við skilgreinum sem architecture og hvað ekki.
Í þessum fyrirlestri er fjallað um architecture og agile og hvernig þessir hlutir geta fallið vel saman. Með aglie teymum flyst mikið af ábyrgð á architecture til teymanna, en samt þarf að vera einhver sameinlegur strúktúr og sýn.
The document discusses several challenges for implementing agile practices in complex projects. It emphasizes the importance of having the right product owner and manager who understand agile principles and can help organize cross-functional teams. Establishing a knowledge base and continuous integration are also highlighted as important for facilitating collaboration across distributed teams working on evolving products.
76 May 2007Vol. 50, No. 5 COMMUNICATIONS OF THE ACM COMMUNIC.docxevonnehoggarth79783
76 May 2007/Vol. 50, No. 5 COMMUNICATIONS OF THE ACM COMMUNICATIONS OF THE ACM May 2007/Vol. 50, No. 5 75
Adding the word architect to a software practitioner’s title seems sim-
ple enough, but beneath the surface fundamentally different thinking,
toolsets, and disciplines are required to succeed. In teaching software
architecture and working as a software architect, database architect, and
chief architect, I have often found that an unfortunate lack of knowledge
surrounds the architect’s role. Even experienced software practitioners are
often unable to define what exactly the architect does or adds to the soft-
ware development process.
THE SOFTWARE
ARCHITECT
B y M a t t h e w R . Mc B r i d e
Leadership is the defining characteristic in
an unforgiving technology arena.
The context for my discussion here is the
construction of enterprise-level business appli-
cations. I chose it for its inherent difficulty and
complexity, though the related architectural
principles may be applied to any type of soft-
ware construction. Specifically, I examine the
results of applying these principles to three sep-
arate development efforts: a product-ordering
Web site, a complex business-to-business inte-
gration project, and the design and develop-
ment of an enterprise application. Regardless
of the situation, my experience has been that
software architects are not born but trained,
sometimes in the school of hard knocks.
Although effective software architects seem to
intuitively understand and guide projects, an
intellectual framework and its associated disci-
plines and tools are behind this thinking.
Reports of IT overspending and project failure
emphasize the fact that these skills must be
developed. Software professionals in a variety
of roles can leverage them to lead software pro-
jects to exceed customer expectations.
Many seminal ideas in software architecture
can be traced back to a speech Christopher
Alexander, a distinguished building architect,
• Explicit requirements explode by a factor of 50 or
more into implicit (design) requirements as a soft-
ware solution proceeds.
Perhaps more than any other task, managing com-
plexity is an essential element of architecture the
architect must address in order to deliver the
promised system. Strategic approaches are high-level,
broad-brush techniques
used by architects to master
complexity across technical
and nontechnical audiences
alike (see Figure 2).
Included are effective com-
munication and informa-
tion gathering, detailed
planning, and the educa-
tion of all stakeholders
regarding all relevant tech-
nologies. Tactical
approaches address the
techniques the architect
employs at a lower level of
detail, typically with those
who construct or use the
system. This group includes software designers, pro-
ject teams, and end users. Requirements planning,
separation of the system into logical layers, and care-
ful interface definition are
only a few of the tactical
tools at the ar.
The presentation is about the discipline of being a Software Engineer, design basics of a software architecture, software engineering fundamentals, and principles. It aims to aware students about software engineering career options,
1996 Enterprise Architecture Praxis Presenation @ ZIFABrian K. Seitz
This document discusses introducing enterprise architecture practices at Microsoft. It begins with an overview of enterprise architecture, including its purpose to manage complexity through reduction and organization. It then discusses Microsoft's experience in establishing an architectural praxis, or process, including organizing architects into teams to augment existing product development groups. The document concludes that the essential elements of an enterprise architecture practice include having architects, an architectural framework, a set of plans, and an architectural process model.
EAC2013 presentation: A Cookbook for Smart EA PracticesRik Farenhorst
Despite the maturation of the discipline, in many organizations Enterprise Architecture is not applied very effectively, mostly because using structured methods and frameworks is preferred over communicating business value and smart planning of IT investments. The various EA frameworks (e.g., TOGAF) that have been proposed over the past years definitely have their merit, but they also seem to seduce architects to focus on blueprints, elaborate process definitions and ivory towers. Architects simply need to work smarter to be of added value. Based on experience in numerous EA projects and EA trainings delivered in the Netherlands, in this presentation a cookbook for smart EA practices is proposed. The cookbook, which is inspired by success stories from the trenches, adopts and adapts elements from contemporary EA frameworks and other methods, (e.g., stakeholder management, architecture visualizations, business model canvas), and as such provides a step-by-step guide for building or professionalizing an EA function.
Oop 2014 embedded systems with open source hardware v2Michael Stal
The document discusses developing software for open source hardware. It begins with an overview of physical computing and the maker movement. It then discusses various open source hardware boards like Arduino, Raspberry Pi, and BeagleBone. The document outlines the prerequisites for building systems with these boards, including basic electronics knowledge. It provides examples of standard components that can be used. It also discusses programming models for embedded devices and provides a "Hello World" example in Arduino.
Qcon2011 functions rockpresentation_f_sharpMichael Stal
This document provides an overview of functional programming concepts and introduces the F# programming language. It discusses core FP topics like immutable values, recursion, and higher-order functions. It then presents an introduction to F#, explaining that it combines object-oriented and functional programming. The document provides examples of basic F# syntax like functions, pattern matching, and the type system. It also illustrates concepts like currying, lazy evaluation, and the pipeline operator.
Qcon2011 functions rockpresentation_scalaMichael Stal
Scala functions provide powerful ways to decompose problems and harness the benefits of functional programming. The presentation introduces core concepts of functional programming using Scala as an example language, highlighting how Scala combines object-oriented and functional programming. It presents benefits like immutability, higher-order functions, and improved concurrency while avoiding past performance issues through modern virtual machines and libraries.
The document discusses architecture refactoring and defines it as changing a software system or process in a way that does not alter external behavior but improves internal structure. It notes that design erosion over time negatively impacts systems and refactoring can help address this. The document outlines some motivations for refactoring like improving structural and non-functional qualities to achieve a more economical, visible, and symmetric design. It also distinguishes refactoring from reengineering and rewriting.
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
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
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
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
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
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
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)