25,99 €
Mehr erfahren.
- Herausgeber: John Wiley & Sons
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Englisch
A strategic state-of-the-art software architecture manual for all skill levels In Software Architect, veteran enterprise and solution architect Michael Bell delivers a hands-on playbook of best practices for aspiring and practicing software architects, seeking to improve their software design, integration, communication, presentation, and knowledge acquisition skills. He explores the career enablement, career planning, self-training, and self-improvement topics you'll need to increase your ability to offer powerful and effective business and technological solutions. In the book, you'll learn how to help companies promote business and technological transformation by implementing modern and first-class software design, deployment, integration, and operations. Software Architect also includes: * A modern software architect's toolbox that includes best practices for multi-dimensional software design and integration in an enterprise quantum computing ecosystem * A breakdown of the various types of software architects, as well as useful self-assessments for aspiring and practicing professionals * Skill acquisition strategies for software architects along with strategic approaches to ace software architecture interviews An indispensable manual for aspiring to be architects, software architects-in-training, and practicing software architects. Software Architect is an essential read for anyone hoping to improve their ability to deliver robust business and technical solutions to enterprises everywhere.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 584
Veröffentlichungsjahr: 2023
Ähnliche
Table of Contents
Cover
Title Page
Introduction: Software Architect, Who Are You?
You Promote Institutional Culture
You're an Astute Strategist
You're a Gifted Leader
You're an Instrumental Solution Provider
You're an Integrator Par Excellence
You're Domain-Driven
You're Socially Driven
You're Career-Driven
You Trust Your Innate Talents
Part 1: Software Architect Capability Model
CHAPTER 1: Software Architect Capability Model
Software Architect Capability Model: Benefits
Requirements Drive Architecture Solutions
Create a Software Architect Capability Model in Five Steps
Step 1: Provide Requirements and Specifications
Step 2: Identify Software Architecture Practices
Step 3: Establish Software Architecture Disciplines
Step 4: Add Software Architecture Deliverables
Step 5: Quantify Skill Competencies
Interview Questions
Notes
Part 2: Software Architecture Career Planning
CHAPTER 2: Types of Software Architects
Business Needs for Technological Solutions
Organizational Leading Software Architect Levels
Types of Domain Software Architects
Collaboration Between Leading Software Architects and Domain Software Architects
Notes
CHAPTER 3: Career Planning for Software Architects: A Winning Strategy
Software Architecture Career Planning Process
Self-Discovery Process: The Six Ws
Carving a Software Architecture Career Path
CHAPTER 4: Self-Assessment for Software Architects
Social Intelligence
Software Architecture Practice
Leadership
Strategy
Part 3: Software Architecture Toolbox
Chapter 5: Employing Innate Talents to Provide Potent Organizational Solutions
Innate Skills Promote Software Architecture Effectiveness
Employ Chief Innate Talents to Become an Effective Software Architect
The Power of Creativity
The Potency of Imagination
Software Design Aesthetic
Curiosity Attributes
CHAPTER 6: Software Architecture Environment Construction
Benefits of the Software Architecture Environment Construction Discipline
Must Haves: Problem Statements and Requirements
Software Architecture Structures
Software Architecture Environment: Driven by an Uncontrolled Quantum Landscape Behavior
Software Architecture Environment: An Intelligent Topological Space
Deformation Aspects of a Multidimensional Software Architecture Environment
Entanglement Effects in a Software Architecture Environment
Software Architecture Environment Forces Drive Software Behavior
Genetic Encoding of a Software Architecture Environment
Influences on Social, Behavioral, and Business Goals
Software Architecture Environment Construction Life Cycle
Construction Laws of a Software Architecture Environment
Best Practices for Software Architecture Environment Construction
Notes
Chapter 7: Structural Construction of Software Implementations in Multidimensional Environments
Software Architecture Solids: Rudimentary Geometrical Design Structures
Software Architecture Dimensional Model
3D Software Structures in a Software Architecture Computing Space
Distribution Styles of 3D Software Implementations in an Architecture Computing Space
Construction Life Cycle of Software Implementations
Governing Laws for Software Construction in a 3D Computing World
Best Practices for Constructing Software Implementations
Notes
Part 4: Software Architecture Interview Preparations
CHAPTER 8: Preparing for a Software Architecture Interview: A Winning Strategy
Software Architecture Job Interview Strategy
Software Architecture Job Interview Defense Plan
Software Architecture Job Interview Attack Plan
Notes
CHAPTER 9: An Outline for Software Architecture Job Interview Questions
Behavioral Questions
Skill Assessment Questions
Software Architecture Attributes Questions
Software Architecture LifeCycle Questions
Software Architecture Concepts Questions
Architecture Style, Architecture Pattern, and Design Pattern Questions
Problem-solving and decision-making Questions
Data-Related Questions
Production Environment Questions
Software Architecture Framework Questions
Notes
Index
Copyright
About the Authors
About the Technical Editor
About the Contributing Editors
End User License Agreement
List of Tables
Chapter 1
Table 1.1: Application Architect Competency Example
Table 1.2: Data Architect Competency Example
Chapter 2
Table 2.1: Levels of Organizational Leading Software Architects and Their Re...
Table 2.2: Enterprise Architect Responsibility Table
Table 2.3: Solution Architect Responsibility Table
Table 2.4: Application Architect Responsibilities
Table 2.5: Types of Enterprise Leading Architects
Table 2.6: Data Architect Responsibilities
Table 2.7: Cloud Architect Responsibilities
Table 2.8: Security Architect Responsibilities
Table 2.9: Business Architect Responsibilities
Table 2.10: Application Architect and Data Architect Collaboration
Table 2.11: Solution Architect and Security Architect Collaboration
Table 2.12: Business Architect and Enterprise Architect Collaboration
Chapter 3
Table 3.1: Career Planning Self-Discovery
Table 3.2: Subjects of Research for Career Planning Process
Table 3.3: Software Architecture Career Goals Setting
Table 3.4: Software Architecture Career Milestones Stetting
Table 3.5: Software Architecture Career Action Plan
Table 3.6: Software Architecture Career Execution Plan with Alternative Task...
Table 3.7: Optimized Software Architecture Career Execution Plan
Table 3.8: Software Development to Enterprise Architecture Career Path
Table 3.9: From Software Engineer to Chief Architect Career Path
Table 3.10: From Data Architecture to Program Management Career Path
Table 3.11: From Operation Engineering to IT Strategy Career Path
Chapter 4
Table 4.1: Social Intelligence Skill Assessment Table
Table 4.2: Software Architecture Practice Skill Assessment Table
Table 4.3: Leadership Competencies Assessment Table
Table 4.4: Strategic Competencies Assessment Table
Chapter 5
Table 5.1: Guidance to Boost Software Architecture Creativity
Table 5.2: Chief Software Architecture Imagination Boosters
Table 5.3: Aesthetic Aspects of Software Design
Table 5.4: Influencing Aspects of Curiosity
Chapter 6
Table 6.1: Properties of Chief Harmonizing Software Architecture Environment...
Table 6.2: Properties of Disharmonizing Software Architecture Environment Fo...
Table 6.3: Software Architecture Construction Balance Example
Table 6.4: Methods for Software Architecture Environment Composition and Dec...
Table 6.5: Integration and Disintegration Design Methods
Table 6.6: Centralization and Decentralization Design Methods
Table 6.7: Chief Elasticity and Inelasticity Design Methods
Table 6.8: Chief Synchronization and Desynchronization Design Methods
Table 6.9: Software Architecture Environment Construction Best Practices
Chapter 7
Table 7.1: Exclusive Structure Relationship
Table 7.2: Internal Structure Relationship
Table 7.3: Software Architecture Solids Summary of Attributes
Table 7.4: Examples of Influencing Factors on the Two Dimensions of Software...
Table 7.5: Examples of Influencing Factors on the Three Dimensions of Softwa...
Table 7.6: Layering a Software Architecture Computing Space Example
Table 7.7: Software Architecture Balance Tipping Factors
Table 7.8: Software Construction Balance Examples Table
Table 7.9: Thicken and Contract Design Methods
Table 7.10: Lengthen and Shorten Design Methods
Table 7.11: Layer and Delayer Design Methods
Chapter 8
Table 8.1: Software Architecture Job Interview Preparation Model
Table 8.2: Job Description Analysis Findings Version 1
Table 8.3: Job Description Analysis Findings Version 2
Table 8.4: Job Description Analysis Findings Version 3
Table 8.5: Cheat Sheet Notes Examples
Table 8.6: Business Information Providers Examples
11
Table 8.7: Company Business Model and Software Architecture Candidate's Disc...
Table 8.8: Environment Technology Stack Discovery
Table 8.9: Industry Common Development Technology Stacks
Table 8.10: Hiring Institution's Industry-Related Applications
Table 8.11: Enterprise Architecture Environment Decomposition Example
Table 8.12: Design Patterns Vocabulary
Table 8.13: Software Architecture Standard Examples
Table 8.14: Software Architecture Guidelines Lingo
Table 8.15: Architecture Tools Category, Features, and Capabilities
Table 8.16: Design Diagrams Example
Table 8.17: Early Architecture Evaluation Methods Examples
Table 8.18: Late Architecture Evaluation Methods Examples
Table 8.19: Systems and Software Quality Standards Examples
Chapter 9
Table 9.1: Software Architecture Life Cycle Stages and Proposed Activities
Table 9.2: Architecture Patterns vs. Design Patterns
Table 9.3: Architecture Styles Examples
Table 9.4: Preparation Data Topics for a Software Architecture Interview
Table 9.5: Software architecture Environment Features
Table 9.6: Examples of Software Architecture Frameworks
List of Illustrations
Introduction
Figure I.1: An Ideal Software Architect Profile
Figure I.2: Software Architecture Alignment Priorities
Figure I.3: Software Architecture Roles And Their Organizational Solution Sc...
Figure I.4: Structural Deformation Of A Software Architecture Environment
Figure I.5: Domain-Driven Software Architecture Solution Scope
Figure I.6: Software Architecture Social Intelligence Pillars
Figure I.7: Software Architecture Career Strategy Perspectives
Figure I.8: Four Leading Innate Talents
Chapter 1
Figure 1.1: Problem and Solution Domains
Figure 1.2: Software Architect Capability Model Creation Process
Figure 1.3: Example of Software Architect Capability Model Requirements
Figure 1.4: Architecture Practices
Figure 1.5: Architecture Disciplines
Figure 1.6: Software Architecture Deliverables Section
Figure 1.7: Architect Skill Competency
Figure 1.8: Creating a Skill Competency Pattern
Figure 1.9: Comparing Architecture Skill Competencies
Chapter 2
Figure 2.1: Business Imperatives
Figure 2.2: Leading Software Architect Levels
Figure 2.3: Collaboration Hierarchy of Leading Software Architects
Chapter 3
Figure 3.1: Career Planning Process
Figure 3.2: The 4-D Software Architecture Career Perspectives
Figure 3.3: Social-Driven Career Chart
Figure 3.4: Software Development to Enterprise Architecture Career Path
Figure 3.5: Technical-Driven Career Chart
Figure 3.6: Software Engineering to Chief Architecture Career Path
Figure 3.7: Leadership-Driven Career Chart
Figure 3.8: Data Architecture to Program Management Career Path
Figure 3.9: Strategy-Driven Career Chart
Figure 3.10: From Operation Engineering to IT Strategy Career Path
Chapter 6
Figure 6.1: Micro-Level Supporting Software Structure Example
Figure 6.2: Software Architecture Environment Structure
Figure 6.3: Software Architecture Environment Topological Space
Figure 6.4: Schematic Relationship of Software Entities in a Software Archit...
Figure 6.5: Impact Representation by Centralized Software Hubs on a Software...
Figure 6.6: Software Architecture Environment Construction Life-Cycle Exampl...
Figure 6.7: Design Activities
Figure 6.8: Composition and Decomposition Design Activities Example
Figure 6.9: Integration and Disintegration Design Activities Example
Figure 6.10: Centralization and Decentralization Life-Cycle Design Activitie...
Figure 6.11: Elasticity and Inelasticity Life-Cycle Design Activities Exampl...
Figure 6.12: Environment Synchronization and Desynchronization Life Cycle De...
Chapter 7
Figure 7.1: Software Architecture Solids
Figure 7.2: Atomic Software Structure
Figure 7.3: Simplified Composite Software Structure
Figure 7.4: Complex Composite Software Structure
Figure 7.5: Two Interface Solids
Figure 7.6: Multiple Interface Solids
Figure 7.7: Inclusive Employment of a Pipe Solid
Figure 7.8: Exclusive Employment of Pipe Solids
Figure 7.9: Internal Employment of Pipe Solids
Figure 7.10: Data Solid Structure
Figure 7.11: Integration of a Data Solid
Figure 7.12: Software Architecture Dimensions
Figure 7.13: Zero-Dimensional Points in a Software Architecture Space
Figure 7.14: One Dimension in a Software Architecture Space
Figure 7.15: Two Dimensions of Software Architecture
Figure 7.16: Three Dimensions of a Software Structure
Figure 7.17: 3D Software Structures in a 3D Software Architecture Computing ...
Figure 7.18: Points and Their Corresponding Origin in Software Architecture ...
Figure 7.19: Three Axes of the 3D Software Architecture Computing Space
Figure 7.20: Software Architecture Computing Space Coordinate System
Figure 7.21: Cardinal and Intercardinal Directions in a Software Architectur...
Figure 7.22: Applying an Intercardinal Directions System to a Software Archi...
Figure 7.23: Combining the Software Architecture Coordinate System with the ...
Figure 7.24: Two Floors in a Software Architecture Computing Space
Figure 7.25: Three-Dimension Federation Style
Figure 7.26: Federated Relationship Style in a 3D Computing Space
Figure 7.27: Flooring Distribution Style
Figure 7.28: Layering a Software Structure in a 3D Computing Space
Figure 7.29: Symmetrical Distribution Style
Figure 7.30: Asymmetrical Distribution Style
Figure 7.31: Software Construction Design Activities
Figure 7.32: Thicken and Contract Life Cycle Design Activities Example
Figure 7.33: Lengthen and Shorten Life-Cycle Design Activities Example
Figure 7.34: Layer and Delayer Design Activities Example
Chapter 8
Figure 8.1: Skill Competency Model for Job Requirements
Figure 8.2: Skill Competency Model Patterns
Chapter 9
Figure 9.1: A Conceptual Model for Software Architecture Life Cycle Stages
Figure 9.2: A Model for Software Architecture Concepts
Figure 9.3: Style and Pattern Hierarchy
Guide
Cover
Title Page
Copyright
About the Authors
About the Technical Editor
Introduction: Software Architect, Who Are You?
Table of Contents
Begin Reading
Index
End User License Agreement
Pages
iii
xxiii
xxiv
xxv
xxvi
xxvii
xxviii
xxix
xxx
xxxi
xxxii
xxxiii
xxxiv
xxxv
xxxvi
xxxvii
xxxviii
xxxix
xl
xli
1
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
285
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
iv
v
vii
387
Software Architect
Michael Bell
Introduction: Software Architect, Who Are You?
As a software architect you’ve embarked on a career journey in an unchartered and unpredictable territory with no guarantee of successful technological solutions. You are employed as a software architect to participate in a corporate business, technological, and social experiment whose chief thrust is to manufacture software products deployed to virtual environments. It's also arduous to foretell the business performance quality and stability after deploying and integrating software implementations in computing ecosystems.
By no means is this a bleak portrayal of a software architecture career. On the contrary, the uncertainty of your contribution to enterprise solutions only opens the doors to business development and transformation opportunities, technological modernization, and career improvement and growth. Furthermore, your hard work and dedication can be achieved through the power of creativity, imagination, and persistence. Once you are resolved to pursue a software architecture career, or are already a devoted practitioner, you're destined for a highly successful journey.
The following sections draw a picture of an ideal software architect whose capability to solve organizational problems is beyond imagination. This profile represents a well-rounded software architect with close-to-perfect professional talents that organizations would most certainly employ if the need existed. However, do not fret or be discouraged. We strive to possess these outlined qualities to make a difference in people's lives by promoting business culture, strategies, mission, and vision.
Figure I.1 illustrates the ideal software architect's attributes: career-oriented, innate traits-driven, strategy-driven, culture promoter, integration-driven, leadership-oriented, solution-driven, domain-driven, and social-driven.
So, ideal software architect, who are you?
Figure I.1: An Ideal Software Architect Profile
You Promote Institutional Culture
You're hired as a software architect to inspire change, stir up enthusiasm for innovation, stimulate new ideas, affect organizational strategies, combat business and technological stagnation, and make a big difference in people's lives.
Become an Agent of Cultural Transformation
You are offered a key position to participate in transforming the old into the new. The former refers to outdated business concepts, traditional ways of doing business, archaic methods of developing software products, and waning technological solutions. The “new,” on the other hand, pertains to modern technologies, creative and practical applications and systems, innovative end-to-end software architecture methodologies and life cycles, and partnerships that promote organizational dialogue to secure the business.
By partaking in such ambitious organizational metamorphosis, you're the de facto institutional agent of cultural transformation. You are actively engaged in a social and technological experiment that touches lives and instills change in people's behavior. This multifaceted cultural change manifests in how people communicate, interface with applications and systems, form relationships and partnerships, run their daily lives, and manage their careers.
So, how do software architects promote organizational culture? The arsenal of tools and utilities employed to impact the environment profoundly is vast. Furthermore, the sky is the limit for technological evolution and innovation. The business and technological solutions you're being asked to provide drive the establishment of organizational policies, best practices, and standards. These rules and procedures you're advocating for promote institutional norms of behavior, foster business alliances, and forge new codes of cultural conduct.
Contribute, Do Not Follow
However, the cultural change that you're promoting does not touch only individuals. You are employed to harness the power of your talents and creativity to form a new generation of ideas and find shared values reinforced by members of your organization inspired by your innovative visions. In reality, you are a benefactor at heart, not a follower. Any organizational solution you offer contributes to the institutional knowledge base and the collective memory of your followers, who are ultimately employed to solve enterprise problems.
Further Reading
Although the topic of promoting organizational culture is discussed throughout the book, refer to these chapters to learn about the specific methods that software architects can leverage to impact institutional culture:
Chapter 3
, “Career Planning for Software Architects: A Winning Strategy” depicts four career-driven perspectives that can impact organizational culture: social-driven, technology-driven, management-driven, and strategy-driven.
Chapter 4
, “Self-Assessment for Software Architects” offers a self-scoring questionnaire that contains queries about promoting organizational culture methods.
You're an Astute Strategist
Your strategic mindset is the key to the success of your software architecture career. No matter which software architecture scope of solutions you pursue, application or enterprise level, focus on the big picture. You're a generalist by nature. Never rush into details to develop effective solutions. Having a bird's-eye view is what makes you an all-around type of person.
You're also a gifted tactician who incessantly occupies your mind with long-term and sustainable solutions to remediate business problems. The prospect of business prosperity and technological continuity motivates you to carve out complicated schedules, road maps, and product development timetables.
No matter the magnitude of your work, your strategic outlook is driven by a thorough study of business and technological events that occur on the ground. Then, by connecting the dots, you deliver superior software architecture artifacts. In this context, connecting the dots pertains to aggregating and utilizing all possible organizational resources, such as subject-matter experts, data, utilities, and facilities, to derive the best possible software and environment implementations.
Adopt an Effective Outside-In Strategy to Deliver Synthesized Software Architecture Solutions
You're an outside-in software architecture strategist attuned to market and industry trends, quality of organizational services, and, most important, customer imperatives. In addition, you are acquainted with advanced product development life-cycle methodologies and often follow business market developments and innovations, valuable knowledge that drives your methodological approach to meeting client requirements. Satisfying these imperatives begins with an effective business discovery and analysis process that leads to software architecture solutions.
Do not be constrained by existing technological limitations. If current organizational technologies tend to narrow the scope of your vision, you must drive change, modernization, and initiatives aligned with your software architecture vision and mission. Furthermore, you drive business and technological transformation through creativity, curiosity, and modernity synthesis. Finally, never deprive yourself of the freedom of imagination when proposing innovative software architecture implementations.
Align Software Architecture Strategies with Organizational Imperatives
As an astute software architecture strategist, you know that your technological vision and mission must align with business strategies. Remember, you're not operating in a vacuum. Your software architecture solutions, therefore, ought to promote business agendas, foster business growth, and ensure business stability and continuity.
However, aligning software architecture strategies with business vision and mission would not promote satisfactory technological solutions. Business cooperation and coordination are indeed primary and compulsory goals for software architects. Their duties, however, must go beyond business imperatives. There are accessorial software architecture strategy alignment necessities to drive a comprehensive enterprise technological balance.
Thus, software architecture strategies must also be aligned with existing deployment environments, supporting infrastructure, development platforms, data and message exchange mechanisms, architecture styles, design patterns, and integration patterns. Again, promote transformation initiatives to satisfy software architecture vision and mission if software architecture strategies cannot align with existing technologies and environments.
Figure I.2 illustrates a software architecture strategy alignment priority example chart that outlines alignment opportunities with business, technologies, environment, and infrastructure.
Figure I.2: Software Architecture Alignment Priorities
Further Reading
The topic of software architecture strategy alignment with business strategy, vision, and mission to propel technological initiatives across the organization is discussed largely in Chapter 2, “Types of Software Architects.” It introduces three business needs for software architecture to foster organizational transformation and modernization: strategic collaboration, technological mediation, and technological implementation
You're a Gifted Leader
You're a leader, not necessarily a manager. You possess noteworthy interpersonal traits. You're a person of integrity who instills trust in your co-workers, managers, corporate executives, and partners. You promote institutional social harmony to foster consensus on software architecture strategies, technologies, best practices, standards, and policies. You're trusting and trustworthy because you have a positive perspective of humankind.
Your natural leadership traits inspire followers. These devoted fans respect your perspectives and are committed to collaborating with you on software architecture projects and business initiatives. As a gifted technological leader and team player, you prefer to collaborate with others. You encourage diversity of ideas and solutions by fostering the collective creativity of enthusiastic technologists. You never impose your views on others—in contrast, you're an advisor, a mentor who offers viable guidance to those who seek professional direction.
TIP Remember, you're a leader. You're not a manager or administrator who signs timesheets and reprimands staff for wrongdoing.
Tolerate Errors and Stay Open to Technological Experiences
Your innate problem-solving and decision-making skills paint a realistic view of your organization's business and technological contribution. In other words, nothing is perfect! You understand the difficulties and constraints of any proposed software architecture solution. And you’re aware of the impact your technical recommendations have on your organization. You're wise to understand that ill-designed applications and systems can cause operational chaos, disrupt business continuity, negatively impact productivity, and harm your company's bottom line.
With all these potential risks to the enterprise, you're still a natural optimist and idealist, a risk-taker willing to surrender short-term gains in favor of strategic long-term technological success. These traits define a person who tolerates design errors, software implementation mishaps, and software deployment and integration flaws. In reality, you're not afraid of failure. In your mind, the design experiment journey you're willing to embark on can only promote successful technological modernization.
Build a Circle of Trustful Followers by Uplifting Their Spirits
As a software architect, you must inspire others and galvanize positive energy among your co-workers and work teams. You're here to foster creativity—the failure of imagination is not an option. You are here to usher intelligent followers who trust your software architecture judgment and good taste, and who are not afraid of making design mistakes or expressing silly opinions.
TIP Remember, you're an experimentalist whose leadership traits galvanize enthusiasm for collaborative teamwork to offer superb technological solutions for sustaining and accelerating business success.
Further Reading
Take the self-evaluation questionnaire provided in Chapter 4, “Self-Assessment for Software Architects,” to find out if you possess the proper software architecture leadership talents that can galvanize enthusiasm for business innovation and technological modernization.
You're an Instrumental Solution Provider
At heart, you are a solution provider. Deep inside you, there is a veiled desire to mitigate risks, resolve social conflicts, and provide guidance to tackle organizational challenges. You always rise to the occasion to remediate business shortfalls. Furthermore, you go the extra mile to seek pragmatic technological solutions.
Promote Business Growth Through Modern Technological Solutions
You are committed to implementing potent strategic foundations for sustainable and viable business growth through technological modernization. You're a risk-taker and venture to support business transformation by leveraging the best-of-breed technical capabilities. Furthermore, you believe that technology is not just a mechanical mean for implementing temporary solutions or for offering Band-Aid remedies that do not withstand time. Simply put, you're a solution provider with technological, strategic agendas that tolerate occasional failures to achieve novel goals.
Provide Solutions Within the Boundaries of Your Software Architecture Expertise
As a software architect, you focus on design solutions—software-oriented remedies, not hardware. This is because you understand the boundaries of your occupation. You're aware that the solutions you provide are within the margins of software architecture practices—the field in which you excel. You may collaborate with co-workers specializing in physical infrastructure, hardware servers, and network devices. However, your chief responsibility is to design applications, services, systems, and deployment environments within your software architecture expertise.
Know the boundaries of your responsibilities. Be aware of your software architecture level of contribution. You're wise to understand that the reach of your technical solutions depends on the boundaries of your position. Namely, the job you're holding as a software architect has restricted outreaching responsibilities. This is not because you cannot accomplish tasks beyond your job description. It's simply due to the software architecture duties you're commissioned to pursue.
Understand the Scope of Your Technological Solutions
So, what would be the scope of your technological solutions?
Nowadays, common organizational practice calls for founding a hierarchical structure of software architecture roles. They are established to address three different levels of solutions. Affiliated with the top layer of a pyramid, enterprise software architects and their technological solutions must meet enterprise-level business imperatives. Then, solutions architects are related to the second layer, just beneath the enterprise architects' level. They are commissioned not only to promote enterprise software architecture strategies, but also to oversee application-level design initiatives. Finally, application architecture roles are the nucleus of any organizational software design initiative. They are positioned at the very bottom of the structural employment hierarchy, assigned to offer solutions for the narrowest range of problems. Figure I.3 illustrates the hierarchical structure of software architecture roles and their solution scope and dependencies within an enterprise.
Figure I.3: Software Architecture Roles And Their Organizational Solution Scope
Further Reading
To learn more about how to scope technological solutions and set boundaries for your professional expertise visit these two chapters:
Chapter 1
, “Software Architect Capability Model,” discusses a method to help scoping technological solutions and setting boundaries to a professional occupation by creating a capability model with five driving sections: specifications, architecture practices, architecture disciplines, architecture deliverables, and quantification of skill competencies.
Chapter 2
, “Types of Software Architects,” elaborates on two types of software architect roles: leading software architects and domain software architects. Each of these roles are commissioned to focus on specific solution scopes.
You're an Integrator Par Excellence
Integration duties are the bedrock foundation of your occupation. It's an integral part of your professional daily practice. No matter what level of software architecture contribution to the enterprise you provide, you’re well aware that integration is a compulsory responsibility that you cannot avoid. It's a software design capability you possess, leverage, and exhibit to satisfy a broad range of business and technological imperatives. Furthermore, integration is a technological, social, and business competence you consistently demonstrate to provide large-scale business remedies. And it's a software architecture aptitude you employ to aggregate solutions mutually provided by a community of software implementations.
Connect the Dots
You're dubbed a “software integrator” because every design scheme you devise proves effective partnerships and communications between software implementations. Any design blueprint you provide presents logical views of interaction and collaboration between applications, services, and systems. And it's starkly apparent that any software architecture environment you design maintains a pragmatic alliance between distributed software assets.
You do not take the term connecting the dots lightly in regard to software integration. Namely, you do not sneeze at opportunities to utilize diverse sources of information, combine people's ideas, and aggregate technological fountains of knowledge to devise powerful software architecture integration solutions. In essence, you're wise to connect the dots to foster software reuse and optimize the redundancy of business functionality.
Integrate Software in a Three-Dimensional Software Architecture Environment
As a software architect, you're keenly aware that integration is not only about connecting the dots and not merely about enabling software entities to talk to each other and exchange information. Indeed, these are vital software architecture tasks that ensure business continuity, ensuing viable organizational solutions.
However, you're also mindful that software implementations do not operate in a vacuum and are deployed to a topological, geometrical, and three-dimensional landscape that offers them adequate architectural conditions to survive in. In Chapter 6, “Software Architecture Environment Construction,” and Chapter 7, “Structural Construction of Software Implementations in Multidimensional Environments,” this ecosystem is labeled the software architecture environment. As illustrated in Figure I.4, this landscape constantly undergoes structural deformation due to the behavior of the hosted software entities.
Figure I.4: Structural Deformation Of A Software Architecture Environment
Mitigate Risks in a Quantum Software Architecture Ecosystem
Your design outcomes consistently demonstrate a compromise between radical software architecture solutions. These negotiated solutions between extreme design approaches contribute vastly to the mitigation of the risks of an unpredictable deployment environment that can negatively impact business execution. Also, you're compelled to adhere to integration best practices, standards, and policies to foster a balanced software architecture environment. Your instrumental integration talents promote a sensible environment balance to minimize the erratic behavior of software. And your surpassing software integration capabilities alleviate the risks of business interruptions.
Further Reading
The book's Part 3, “Software Architecture Toolbox,” represents the Multidimensional Software Architecture Construction (MSAC) methodology. This design approach offers use cases, best practices, and construction laws for software implementations and their affiliated environments:
Chapter 6
, “Software Architecture Environment Construction,” is all about integration of software in a multidimensional software architecture environment hosted in production.
Chapter 7
, “Structural Construction of Software Implementations in Multidimensional Environments,” represent the 3D structural composition of software entities that are deployed and integrated in a software architecture space.
You're Domain-Driven
You're well prepared to tackle business and technological problems by employing your software architecture talents. There is nothing that can swerve your focus from fulfilling your goals. Furthermore, your uncompromising devotion to offering effective and sustainable software architecture solutions is immeasurable to your organization. Your steadfast resolve to tackle business challenges is attributed to your laser-beam focus on critical problems while avoiding personal agendas and evading trivial issues.
Simply put, the secret of your unwavering commitment to providing best-of-breed software architecture solutions is rooted in your ability to concentrate on what matters. More specifically, your solutions align with corporate business and technological strategies; software architecture vision and mission; leadership directives; and institutional best practices, standards, and policies.
TIP In a nutshell, you're a domain-driven software architect familiar with the business environment, the industry, the customers, and the supporting technology.
Align the Orbit of Your Software Architecture Solutions with Organizational Domains
The alignment of software architecture solutions with business imperatives characteristically yields robust technological solutions. In this context, business imperatives refers to different types of requirements. As a pragmatic software architect you can tailor technological solutions to specific business needs. More explicitly, your solutions to business problems may be affiliated with a specific business sector, business industry, business product, business portfolio, line of business, or business division. These particular business domains drive the technical remedies you propose.
However, business needs do not always drive the domain alignment process. Equally significant is the alignment of software architecture strategies with business strategies. The chief reason is that business strategies are the empirical driving forces in the enterprise. Therefore, technological solutions should foster and support long-term business plans, business models, business vision and mission, and business policies.
Moreover, from a domain alignment perspective, you're most certainly aware that the existing technological capabilities of your organization (such as infrastructure, platforms, and networks) must support software architecture solutions. In some cases, the existing technological capacity may not be advanced enough to deliver your proposed design. Therefore, promote technological modernization and transformation initiatives to improve the alignment with your architectural vision and mission.
Delineate the Scope of Your Software Architecture Solutions
Your devotion to providing software architecture solutions to specific organizational imperatives accelerates time-to-market and ensures business and technological continuity. Pinpointing the sources of business obstacles, devising feasible solutions, and mitigating domain-related issues are prescriptions for software architecture success.
TIP By accomplishing this, you're essentially accredited as a domain-driven software architect who is business-driven, strategy-driven, technology-driven, solution-driven, and leadership-driven. Leverage these capabilities to respond to business and technological necessities.
Again, aligning your technological solutions with organizational domains promotes pragmatic software architecture. Therefore, it's highly advisable to create a solution-focused domain diagram similar to the one shown in Figure I.5. Such a depiction will demonstrate the various opportunities for software architecture success. Focus on your organizational domains that require attention. Leverage your leadership talents to focus on particular business and technological problems. Finally, focus only on domain challenges that require solutions.
Figure I.5: Domain-Driven Software Architecture Solution Scope
Further Reading
As a domain-driven software architect whose duty is to deliver a balanced software architecture, focus on the software architecture construction life cycles, governing laws, and best practices covered in Chapter 6, “Software Architecture Environment Construction” and Chapter 7, “Structural Construction of Software Implementations in Multidimensional Environments.”
Furthermore, to foster a software architecture environment equilibrium, employ your domain-driven design skills to meet business, strategy, technology, solution, and leadership imperatives.
You're Socially Driven
As a software architect, you're mindful that social collaboration and partnership with co-workers, industry alliances, customers, and stakeholders yields compelling technological solutions. Technical solutions have never been successful without teamwork and cooperation with subject-matter experts (SMEs). Individuals promoting personal agendas can never deliver substantial software architecture strategies.
In conclusion, software architects should fulfill their duties through the power of social intelligence. Moreover, architects who snub social skills to better accomplish the tasks they were hired for often find that their software architecture solutions ultimately fail to live up to organizational expectations. Simply put, the respectful and productive interrelationship between technologists and business leaders always demonstrates social capabilities that deliver perceptive technological solutions.
Leverage the Contribution of Social Intelligence to Your Software Architecture Career
In this context, social intelligence pertains to your ability to understand yourself, your needs, and your limitations. However, it's not only about your imperatives or boundaries. This self-acumen is about the capability to know others, the aptitude to understand the environment, and the faculty to develop trustful and sustainable partnerships in the workplace.
Have a look at the chief social intelligence tokens presented in Figure I.6. These represent software architecture social intelligence capabilities leveraged to drive powerful business and technology transformation solutions: agility, adaptability, and awareness.
Figure I.6: Software Architecture Social Intelligence Pillars
Awareness is a unique social talent that can be leveraged to cope with complex social, business, and technological changes and challenges thrown your way. The term adaptability stands for versatility—an attribute that describes a skillful person with multiple talents for tackling organizational problems. Moreover, agility is a personal quality of a software architect who knows how to negotiate and compromise on technological solutions, resolve social conflicts, and collaborate with others in good faith.
Follow a Simple Process to Leverage Your Software Architecture Social Intelligence Skills
Your social intelligence skills can be instrumental in establishing working-related partnerships and alliances. To build a coalition of supporters and collaborators, consider these simple roadmap milestones: search, connect, integrate, and cooperate.
At the onset of this exertion, begin searching for candidates who understand your language and objectives and are willing to work together to achieve software architecture goals. While these individuals are typically found in close vicinities, such as in your organization, others can be spotted on social media and at technological conferences.
Once potential social partners are found, devote your time to connecting, raising their interest, and spurring enthusiasm for contributing to the organization and industry. Then share your knowledge. Learn from others. Interface and cooperate on strategies. And always remember: you're not alone!
Further Reading
The topic of software architecture social intelligence skills is covered chiefly in these two chapters:
Chapter 4
, “Self-Assessment for Software Architects,” includes queries to evaluate an individual's communication, collaboration, and partnership formation skills required to promote software architecture strategies and contribute to technological transformation and innovation.
Chapter 9
, “An Outline for Software Architecture Job Interview Questions,” introduces potential interview behavioral questions, preparing candidates to demonstrate communication, interpersonal relationship, and leadership capabilities.
You're Career-Driven
It's critical to carve out a long-term plan, a strategy that reflects your talents and capabilities. Equally important, stay attuned to your individual preferences, such as the types of duties that you'd like to fulfill and contribute to a specific sector and industry. However, focusing merely on your career agenda or promoting individual interests would never contribute to solving organizational problems or boosting your software architecture performance.
Remember that your preliminary duty is to collaborate with co-workers and partners to support business objectives—a vision greater than your aspirations. In software architecture, there is nothing nobler than teaming up with stakeholders to promote organizational culture, influence the outcome of business transformation, and accelerate technological modernization.
Carve Out a Software Architecture Career Strategy
A software architecture career strategy is a long-term plan that spells out incremental steps to achieving professional milestones and goals. Each milestone is an important landmark, a checkpoint for evaluating your professional progress and achievements. A career milestone can also mark a turning point, perhaps a change in direction or adjustment to your software architecture employment strategy.
The software architecture career strategy's goal should not be considered your last professional occupation. On the contrary, in a long-term career time span, there may be multiple goals to pursue. Again, each milestone assessment should determine the next career step to conquer.
Moreover, a software architecture career strategy ought to be realistic. And professional development in the field must be gradual and feasible. The journey to achieving career goals should be devoted to knowledge acquisition, self-improvement, and delivering best-of-class software products and the architecture of their hosting environments.
Knowledge acquisition refers to the incremental learning and practice of software architecture disciplines during career employment. Specifically, business and technical knowledge are acquired through years of hard work, research, and studies. Self-improvement is related to the knowledge acquisition process. But it is affiliated chiefly with self-motivation and the individual appetite for improving software architecture capabilities.
TIP Bottom line: a software architecture career strategy encompasses a gradual and self-challenging agenda that should be reevaluated at every milestone.
Software Architecture Career Strategy Perspectives
Throughout the years, the software architecture field has grown immensely in scope. Professionals choose to focus on different architectural practices and disciplines. Some individuals pursue the leadership and governance route, while others focus merely on the technological aspects of software architecture roles. As illustrated in Figure I.7, this book centers on four chief software architecture career planning perspectives: social, technology, strategy, and leadership.
Social-Driven Career Perspective
Consider this employment avenue if you seek to promote your professional objectives by forming productive alliances with collaborating partners and executives to provide business and technological solutions.
Technology-Driven Career Perspective
If you focus merely on your technical skills, pursue this career path by applying software architecture capabilities and experience to provide business and technological solutions.
Leadership-Driven Career Perspective
Choose this career path if you possess management skills and seek to focus on promoting enterprise culture, steering technological transformation, and establishing institutional best practices, standards, and policies.
Strategy-Driven Career Perspective
This role is for you if you look to influence enterprise business and technological evolution, foster digital transformation, develop organization-wide road maps, and align business strategies with software architecture strategies.
Figure I.7: Software Architecture Career Strategy Perspectives
Further Reading
A well-planned career path is a roadmap for a successful software architecture journey. But a career strategy is not the only ingredient for a flourishing occupation. Knowledge acquisition and carving out a winning strategy for software architecture interviews can indeed yield a lifetime of prosperous employment.
Chapter 3
, “Career Planning for Software Architects: A Winning Strategy,” depicts the four career-driven perspectives that can impact organizational culture: social, technology, management, and strategy.
Chapter 8
, “Preparing for a Software Architecture Interview: A Winning Strategy,” introduces a job interview preparation model that includes two different strategies to consider: interview defense and attack plans.
Chapter 9
, “An Outline for Software Architecture Job Interview Questions,” presents potential software architecture questions that can increase the odds of acing an interview. They are grouped into ten different categories, such as technical, behavioral, social, problem-solving and decision-making, software architecture life cycle, and more.
You Trust Your Innate Talents
You undoubtedly bring a slew of talents instrumental in providing effective software architecture solutions to organizational problems. Moreover, you know that these personal traits successfully contribute to your employment duties. You may have wondered if these individual aptitudes were with you at birth, or perhaps you've learned them on the job.
Numerous scientific studies submit that the talents you have been carrying since birth are recognized as innate traits—skills not necessarily learned through experience. These are affiliated with primal instincts—natural survival abilities such as endurance, social bonding, adaptability, enthusiasm, and more. We often employ them to endure economic hardships, social challenges, or natural calamities.
However, there is no indication that these survival abilities cannot be learned and honed during a lifetime, career journey, or professional training. And it has become evident that combining innate talents with on-the-job experiences improves the ability of software architects to deliver pragmatic and potent solutions. For example, software architecture capabilities to construct powerful applications and systems typically depend on professional traits such as balanced decision-making, effective problem-solving, and good taste.
Employ Innate Traits to Advance Business and Technological Missions
It is no secret that tempestuous organizational issues often challenge software architects. Some are affiliated with the struggle to advance software architecture roadmaps, visions, missions, and strategies. Fostering and maintaining technological leadership is another difficulty that software architects wrestle with. Facing stiff resistance to business change or technological modernization initiatives is another predicament that must be tackled.
Employ your communication, patience, and self-discipline capacities to alleviate unnecessary conflicts. Respect the diversity of ideas, concepts, and solutions your co-workers, managers, and partners propose. Consider their diverse approaches to solving software development and integration problems. Most importantly, stay tuned with the four innate talents that can enhance your decision-making capabilities (as illustrated in Figure I.8): creativity, imagination, software design aesthetic, and curiosity.
Avoid Self-Induced Software Architecture Blindness
Ignoring your innate skills when you need them the most promotes business stagnation, delays technological standardization, and stalls applications and systems modernization. There is nothing riskier to business development than the underutilization of fundamental innate skills, such as creativity and imagination.
Creativity and imagination are all about the enablement of business opportunities. They are the bedrock of every software architecture implementation that allows the business to flourish and win the competition. On the other hand, curiosity is an essential innate gift that galvanizes research and studies and ultimately encourages perfection. Finally, the design aesthetic is an innate skill that entices consumers to buy goods, acquire services, and look forward to the next line of innovative products.
Figure I.8: Four Leading Innate Talents
TIP Do not engage in self-induced software architecture blindness by overlooking your innate traits.
Further Reading
Refer to Chapter 5, “Employing Innate Talents to Provide Potent Organizational Solutions,” to learn more about the chief innate gifts that software architects should leverage to mitigate enterprise challenges and successfully promote software architecture agendas. This chapter also elaborates on a variety of methods to boost software architecture creativity, imagination, good design taste and aesthetics, and curiosity.
Part 1Software Architect Capability Model
In This Part
Chapter 1:
Software Architect Capability Model
CHAPTER 1Software Architect Capability Model
Many information technology (IT) and business professionals often fail to provide clear answers to these three fundamental questions: What do software architects do? What artifacts1 do they deliver? How should architecture skills be assessed, quantified, and vetted?
At a first glance, these sound like easy queries to address. The conventional notion that a software architect fulfills the same duties as a building or landscape architect is utterly incorrect. There is no parallel between these two occupations, because they exercise different practices in distinct fields of expertise. Furthermore, they are commissioned to achieve dissimilar goals.
A software architect is required to perform a vast number of activities, typically handled by more than one professional. So, is it possible to deduce from these tasks what architects actually do or what they deliver?
In the context of this chapter, the simplest answer we offer to such challenging questions is this:
A software architect does what a specific organization needs—nothing more!
This assertion is deliberately too broad. This concept affirms, however, that a software architect must respond to business and technological requirements of a particular organization. In other words, architecture tasks and deliverables vary from one institution to another. Moreover, while working for different lines of business, architects seldom tackle the same challenges, nor do they always provide solutions for similar problems.
This chapter, therefore, offers a simple architect capability model with step-by-step instructions—assisting individuals and organizations to answer these three important questions:
Occupation
What does a software architect do?
Deliverables
What should a software architect deliver to provide potent organizational solutions?
Capabilities
How should software architecture talents be vetted, assessed, and quantified to ensure successful facilitation of enterprise projects?
Software Architect Capability Model: Benefits
The software architect capability model can be leveraged by organizations and individuals to promote business and personal professional agendas. When it comes to fostering enterprise business strategies and missions, the offered architect capability model will provide limitless opportunities for business growth. The model will become a potent platform for project improvement and a tool for recruiting exceptional architecture talents, subsequently minimizing enterprise expenditure.
Individuals who aspire to become software architects will find the capability model a powerful tool for career change and professional promotion. For those already actively pursuing the architecture practice, the model can boost their aptitude to provide robust remedies for organizational challenges.
How Should Organizations Utilize the Software Architect Capability Model?
Onboarding IT personnel is utterly costly. Not only does the interviewing process consume human resources, but also candidate vetting typically puts strain on employees whose daily schedules get disrupted. But the chief challenge is even harder: many organizations do not utilize any methods to evaluate candidates' skill sets. Moreover, there is no benchmark or assessment methodology in place to quantify interviewees' knowledge of and capability to perform the jobs they are applying for.
Furthermore, to a large extent there is no industry-wide model that organizations can leverage to ensure that a software architect talent will indeed contribute to a specific enterprise project. Put differently, there is no method in place to map a software architect's capability to facilitate enterprise imperatives. The consequences of screening failures are typically dire: allocated budgets evaporate quickly, and returns on investment never materialize. Another concern to contemplate is dwindling or inadequate institutional technical knowledge. This can hinder the fulfillment of organizational strategy, vision, and mission.
To address these enterprise concerns, consider the following list. It summarizes the organizational benefits when constructing software architect capability models.
Hiring process
Improving the vetting mechanisms of candidates to enable hiring the best possible talent in the marketplace
Project management
Delivering powerful business solutions by assigning adequate architecture skills to a project or any other enterprise initiative
Organizational knowledge base
Maintaining a robust organizational knowledge pool by retaining the most experienced workforce
Why Create a Personal Software Architect Capability Model?
It's not just enterprise managers who are hiring who should figure out how software architects ought to promote organizational business goals and strategies. Architects, too, should individually be motivated to ascertain what their personal contributions should be to an organization or an industry.
By creating a personal software architect capability model, individuals will be able to assess their competence strengths and weaknesses in the space of software architecture. Then they can further leverage the model's findings to augment their knowledge for the purpose of honing the craft of their occupation.
Another compelling reason for creating an individual architect capability model rests upon the fact that useful organizational solutions are always delivered by software architects who are fully aware of their professional capabilities.
The list that follows, then, reflects the notion that personal goals should be intertwined with organizational imperatives—neither could survive without the other.
Ascertaining personal knowledge gap
Revealing what additional skills a software architect would need to become more instrumental when providing solutions to organizational problems
Preparing for job interviews
Constructing a personal architect capability model would divulge what type of technical and/or business skills are necessary to obtain certain architecture positions
Planning for career opportunities and job promotion
Assisting with establishing a sound career path for pursuing higher-level positions in organizations
Rudimentary Guiding Principles
While constructing the software architect capability model, as guided in this chapter, either for personal or enterprise needs, adhere to these essential principles:
It's all about the “what” and the “how.”
As mentioned in the introduction of this chapter, an architect capability model addresses these simple questions:
What do software architects do? What do they deliver
?
How should their skills be vetted and assessed?
It's all about delivering solutions.
Software architects are hired to provide
solutions
to organizational problems.
It's all about teamwork.
Architects do not operate in a vacuum, nor are they employed to pursue their personal agendas without benefiting the enterprise's strategies and vision. They must collaborate with business and IT professionals to deliver potent remedies for arising organizational challenges.
Software Architect Capability Model Creation Process
The list that follows summarizes the process for creating a software architect capability model. For each of the items in the list, a corresponding section in this chapter meticulously discusses the building block of every step of the way.
Step 1: Provide requirements and specifications.
This section offers insight about the necessary requirements and the role they play in driving architecture solutions.
Step 2: Identify software architecture practices.
This section elaborates on the practices segment of the capability model. It conveys how vital architecture occupations are for meeting business requirements and technical specifications.
Step 3: Establish software architecture disciplines.
The architecture disciplines portion of the capability model defines areas of knowledge, fields of expertise, and specialties that a software architect must possess to provide effective solutions for business and technological imperatives.
Step 4: Add software architecture deliverables.
The deliverables segment of the capability model identifies the required architecture artifacts associated with each discipline.
Step 5: Quantify skill competencies.
This part of the capability model depicts an architect's level of aptitude to deliver valuable artifacts for a project or any other enterprise initiative.
Requirements Drive Architecture Solutions
Deeply rooted in almost every product development life-cycle methodology, requirements are being delivered in response to organizational imperatives. Some requirements aim to fulfill business vision, mission, strategies, and even marketing endeavors. Others are designed to address business challenges related to market competition and survival.
The software design work that an architect provides has a staunch correlation to particular problems that requirements seek to address. Therefore, architects must meet requirements to provide tangible organizational solutions.
A software architect capability model must be driven by requirements. Without requirements, solutions could not be provided. Lack of solutions, consequently, may expose a business to inordinate risks.
The sections that follow, therefore, address three fundamental questions:
Events
What are the chief events that trigger the issuance of requirements?
Entities
What are the organizational entities chartered to deliver requirements?
Requirements
What type of requirements are necessary for constructing useful architect capability models?
Requirements Issued by Problem and Solution Domain Entities
In almost every corporation there are two different subject-matter expert (SME) groups, responsible for addressing internal and external organizational challenges and unforeseen events that can hamper business operations.
Problem domain
Typically affiliated with the business unit, performing a variety of tasks, such as risk analysis, business analysis, product management, business requirements, business strategy, business architecture, marketing, etc.
Solution domain
Characteristically a part of an IT organization that employs architects, developers, technical writers, operation personnel, cybersecurity experts, and others
How Do the Problem and Solution Domains Collaborate?
There are innumerable business adversities that an organization must tackle—for example, loss of revenue, increased market competition, or marketing challenges. The problem domain group (the business), therefore, must confront these issues by pursuing appropriate actions. In many cases, the business advocates the construction of innovative applications and the launch of new projects.
Figure 1.1: Problem and Solution Domains
So, how do business (problem domain) and IT organization (solution domain) collaborate in such cases to provide viable solutions? Figure 1.1 depicts an example of cooperation between these two domains.
The problem domain carves out business requirements to address one or more of the following issues:
Threats
Internal or external threats to the business, such as security attacks and industrial espionage of trade secrets
Motivation
Motivations to promote the business, such as growing market competition
Opportunities
Business opportunities to gain market share, such as sponsoring new products and acquiring companies
Others
Other incentives
Then the solution domain responds to the business requirements by tasking IT professionals with two chief deliverables:
Issuing technical specifications, also known as technical requirements
Driving technical specifications and tangible solutions, such as designing, coding, testing, deployment, and integration, to address the business problems
It must be noted that the scenario in Figure 1.1 is for demonstration purposes. It is an example that may not apply to all organizations. The business group that issues business requirements is not always the prime mover for launching projects in the enterprise.
In other words, requirements for new projects may also be delivered by IT personnel concerned with different issues. These may include security attacks, performance degradation, insufficient computing capacity, or even technological innovation initiatives.
Recall that other divisions or departments not affiliated with the problem or solution domains may also issue requirements for a variety of projects.
Important Facts to Remember
The following list summarizes the chief takeaways of this section:
Software architects
Architects are commissioned to provide software solutions, and therefore they are chiefly affiliated with the solution domain unit of an organization.
Business requirements
These types of requirements are characteristically provided by problem domain professionals—in many organizations by the business department.
Technical requirements
Also known as technical specifications, these types of requirements are delivered by the solution domain (IT personnel).
Project requirements issued by IT
There are instances when the solution domain provides requirements for technical projects.
Other requirements
Other divisions or departments within the enterprise may also be able to issue requirements for specific projects.
Scope of requirements
The architect capability model requirements could support small-scale projects or large organizational initiatives.
Create a Software Architect Capability Model in Five Steps
The sections that follow elaborate on the construction process of the software architect capability model, as illustrated in Figure 1.2. The following list identifies five steps that summarize chief activities to create an efficient skill competency model:
Step 1: Provide requirements and specifications.
We start creating the model from the requirements section. It includes the business requirements and technical specifications, issued by the problem and solution domain organizational entities, respectively.
Step 2: Identify software architecture practices.
The next step is all about establishing the software architecture practices. They are driven by business requirements and technical specifications.
Step 3: Establish software architecture disciplines.
Under each practice we then add the corresponding disciplines.
Step 4: Add software architecture deliverables.
Then architecture deliverables are added to interrelated disciplines.
Step 5: Quantify skill competencies.
Last, the skill competency section is created to specify the expertise level of each architect.
Figure 1.2: Software Architect Capability Model Creation Process
Step 1: Provide Requirements and Specifications
As indicated at the beginning of the section “Requirements Drive Architecture Deliverables,” we must start with requirements to build the software architect capability model.
