2. Roundtable Purpose
Get a sense if the Solution Architecture
Training and CITA-A Certification
would be valuable for you
professionally and for what you do at
your company
3. Approach
Start with context: Solution Architect role and CITA-A certification
50,000 foot view of key modules: highlights according to Don and Rakesh
Business technology strategy
Solution architecture
Lifecycle
Success metrics
Stakeholders
Describing the solution
Deeper dive into Solution architecture module
Finish with review of module's workshop to provoke thoughts
Basing on our personal assessments of value--inviting discussion: what
resonates? do you see it differently? gaining any insights?
4.
5.
6. Module 0 - Business Technology
Strategy
Compares traditional IT Architecture purpose, to enable business
units through technology, to higher calling: use technology to
transform business
Ford Sync, Garmin and digital maps, MRI scanner, Avis pay-at-return
Shows Business architecture model examples such as Strategy
Map, Balanced Scorecard, Roadmaps
Compares Business Technology Strategy to Business Architecture
BTS is lifecycle for managing change , understanding the businsee, and
elevates financial and value arguments reltive to technical one
BTS is common techniquest, BA is form role and accountability for tasks
Compares life cycles of C-Suite, EA, and Projects
7. Module 1 - Solution Architecture
Compares Solution Architect to Software Architect
Solution Architect: skill necessary to deliver end to end solution with
general skills in all four specialization areas
Software Architect: specialist role with depth of skills and experience
in software intensive systems
Describes two "tracks" of Solution Architecture: specialist and
end-to-end or generalist
Summarizes differences between Solution Architect Generalist
and Enterprise Architect
Level of depth to go into when creating strategy for all four areas
Workshop had us create a Solution Architect job description to
support staffing up the architecture department for the fictitious
company
8. Module 2 - Lifecycle
Includes review of industry architecture lifecycles such as
FEAF, Togaf, COBIT and others such as Gated, Agile, Iasa
Solution Lifecycle
Workshop was to create an architecture lifecycle to meet
circumstances of fictional business - similar to task in front of
Don
9. Module 3 - Success Metrics
All about defining value in business terms and relating
architecture work to increasing business value
Architecture value measures are more than participating in projects
that are on-time, within budget, meeting requirements
Describes models like Balanced Scorecard, Business Model
Canvas and others.
Workshop had the class create a Business Model Canvas for
fictitious company
Good for "reverse engineering" business objectives allowing better
linkage of architecture strategies, models, and other deliverables to
business-recognized value
10. Module 4 - Stakeholders
Covers human dynamics aspects of being an Architect
Communicating, influencing, motivating, working with stakeholders with different
backgrounds
Great slide on different motivations of stakeholders and how to address
them at different levels to move a meeting along
Workshop was to create and deliver presentation to executives
persuading them to endorse important architectural objectives for the
fictitious company
11. Module 5 - Describing the Solution
Addresses viewpoints and perspectives and industry
approaches to describing them such as 4+1, Archimate, Woods
and Rozanski, etc.
Workshop was to create a "Viewpoint Library"--very much on
topic for Don
12. What Iasa Says About Solution Architecture Is
The art and science of designing and
delivering a technology strategy against
a measured set of goals and objectives
through a time-constrained set of
activities.
13. Solution Architects Balance Conflicting Forces
Enterprise
• Standards and Constraints
• Strategic Goals
• Target State
Technology
Value
• Increased
ROI
• Constituent
Value
• Market
Opportunities
Project
• Timeline
• Budget
• Team (stakeholders)
Stakeholder
• Requirement
s
• Org
Dynamics
• Conflicting
Goals
Balanced
Solution
14. Solution Architects Work Across Four Domains
Software
• Applications
• Quality Attributes
• Technology Framework
• Maintenance
Infrastructure
• Hardware
• Network
• Frameworks
• Operations
Information
• Data Storage Retrieval
• Information Usage
• Integration
Business
• Goals
• Target State
• Business
Value
15. What Solution Architects Do
• Select and recommend high-value generation approaches for
technology investment
• Generate documents representing the target state value from
technology and functionality of a particular solution
• Review design and architecture documents from extended
team members
• Represent the benefits and costs of chosen technical
direction with stakeholders
• Ensure the ongoing delivery against target state architecture
through build and run phases
• Evaluate the effectiveness of delivered solutions against
planned value
• Communicate value generation throughout the business
environment
• Ensure compliance with internal and external standards and
regulations
16. Solution Architects Perform Different Activities at Each
Scoped Level in the Organization
Select Projects
• Create/Review business case
• Calculate and communicate
value
• Prioritize and select
• Assign architects
Create Architecture(s)
• Capture and analyze
requirements
• Architecture master
•Generic architecture
• Product specific architecture
• Architecture Prototype
• Views/viewpoints
Deliver Architecture(s)
• Stakeholder communication
•Modify and update artifacts
• Delivery
Higher Level
Manage Architecture
• Review and analyze value
• Set architecture goals
• Update Engagement Model
•Communicate value
Project Level
17. How they’re connected with other Architects in the Organization
Finance Sales LOB IT
Business Capability
Data Center
Solution Architects
Software
Architect
Software
Architect
All architects
are included
Specialists
cover
appropriate
areas
Value “rolls up”
Value is clear
to customer
Credit is given
appropriately
Career growth
supported
Business
Architects
Information
Architects
Infrastructure
Architects
Enterprise
Architects
18. Their Project Coverage: Scope of Engagement
Finance Sales LOB IT
Business Capability
Data Center
Solution Architects
Software
Architect
Software
Architect
Business
Architects
Information
Architects
Infrastructure
Architects
Enterprise
Architects
3-5 Projects
Single Project
All Projects
Both Single and Multiple
Both Single and Multiple
19. Why You Should Care – As Is
Set
Goals
Measure
C-Suite
Execute Fund
Portfolio
Mgmt.
Plan EAs
Governance
Asset Mgmt.
Milestone
Review
Measure
Project
Architects
Deliver Design
Project
Architects
Project
Architects
Project
Architects
Project
Architects
20. Why You Should Care – To Be
Set
Goals
Measure
C-Suite
Portfolio
Mgmt.
Asset Mgmt.
EAs
Milestone Governance
Review
Execute Fund
Plan
Design
Project
Architects
Measure
Deliver
Design
Project
Architects
Project
Architects
Project
Architects
Plan
Measure
Project
Teams
Deliver Design
Plan
Measure
Project
Teams
Measure
Deliver Design
Plan
Project
Teams
Deliver Design
Plan
Measure
Project
Teams
Deliver Design
Plan
Measure
Project
Teams
Deliver Design
21.
22.
23.
24.
25. Takeaways
Are you a complete Solution Architect? Do you want to be?
Which type?
Multiple paths to all you need to know and be skilled in
Iasa Solution Architect training followed by CITA-A certification has
Don and Rakesh's stamp of approval
Online classes going regularly
Travel's good: But Seattle in rainy season? Austin in summer?
Let's consider organizing and filling a class here
Editor's Notes
A solution has many often conflicting forces or influences which constrain the output. As architects we approach each of these constraints without bias looking for the most balanced output possible which meet or exceed target measured objectives.
The architect uses these influencers to balance each other as well. Stakeholder concerns are often tactical or focused on non-customer facing optimization, while enterprise goals can be lofty and hard to implement within the tight constraints of a project. The project team may create significant architecture drift in the project using time pressures as a reason for governance exemptions. All of these impact the successful value created in the project.
The architect has many tools to use in a target solution and many areas to optimize their strategy. A full solution architecture includes necessary views in business, information, infrastructure and software. These views may be created by the solution architect in smaller projects or may be created by a team of depth architects with a lead in each area in more complicated projects.
Part of the difficulty with the role of solution architect is that they often need enough skills in each specialization to create the strategy for all four areas. This is also true of enterprise architects but at a different level of depth. Many organizations have difficulty navigating the difference in specialists, those architects with depth in one of the specializations, and generalists like the solution architect who have some skills in each but not the depth of a specialist. This is one reason organizations adopt external standards like those from Iasa to help navigate those complications.
Regardless of how the architects are aligned and staffed, every functional IT organization has a model project cycle, or methodology. Usually this consists of:
Portfolio construction and prioritization
Selection of projects
For each initiative or area (sometimes per project), creation of architecture and associated artifacts
Framing individual projects with specified resources and objectives and specifications and/or requirements
Implementation (often called PMO)
Solution delivery, including release management and transfer to operations; cleanup of architecture artifacts
Realization of the project’s solution (and value)
IASA recognizes several specialties within architecture and the organizational alignment of these roles is often very important in terms of what value can be enabled in the business units. Designing the organization is often a complex exercise to triangulate what skills are present, where certain types of systems may exist, and where optimal value may exist. Even if your organization does not use these exact terms, coverage of the disciplines is still important and the specific job roles should have similar outcomes.
All architects are included
Specialists cover appropriate areas
Value “rolls up”
Value is clear to customer
Credit is given appropriately
Career growth supported
Solution architects typically work on multiple projects and multiple lines of business
Software architects growing skills, working on single project start to finish
Each type of architect may have a different “lifespan” with a given initiative or project. Some may be engaged only in certain phases, whereas others may have specific leadership during the entire project.
Enterprise architects typically have touch points on each project.
Info and biz architects work on both single projects and multiple projects
Example – Google does search, data very important to them
Infrastructure architects – both single and multiple projects at a time
Solution architects – 3-5 projects at a time
Software and infrastructure architects – single project
Context is captured in a process known as current state analysis- this covers all aspects of the “as-is” state, from stakeholder perspectives, to help desk calls, to systems architecture today. This builds a picture that we will modify through the course of a project, to deliver some amount of change. The architect always grounds plans in a grounded assessment of current state.
Fundamentally, as an architect, you need to know what a business is, and how, and why, it operates the way it does. It is imperative for you to comprehend that you are tinkering with an entity that employees people, delivers value to customers, and generates revenue for shareholders. As you create solutions, the effectiveness of these solution can lead to business success, or business failure.
As an architect, you need to understand the type of business environment you will be entering so that you can understand the goals and objectives of the stakeholders and the problem domain. In order to interact effectively, you must understand the “business of the business”, or what they are trying to successfully accomplish.
The architecture you create must be consumable by the business in such a way that leads to business success. The only way to make that possible is to understand the business, and make the architecture relevant and actionable to the business and it’s goals.
The architect the seeks to understand how the future state will be realized, we call this the “to-be” state. Often this involves examining resources for cost estimation, providing stakeholder management or user change management, and framing a project in concrete terms (of budget, people, scope).