SATURN 2014 Building a Community of Practice Session (notes)

Notes by Scott Shipp, edited by Tamara Marshall-Keim

Creating a Sustainable Architecture Organization
William Beshilas, PwC

Opening question: How many of you lead or manage architects? (show of hands: about 50%)

Agenda:

  1. Intro
  2. Reasons to mature
  3. Office of architect
  4. Rollout approach
  5. Making change stick

INTRO

PwC consults to IT organizations, so he points out that this talk is very IT-centric, due to the nature of PwC’s business.

They’ve used this framework on over 30 clients.

REASONS TO MATURE

Why do clients engage PwC?

  • To bridge the gap between the business and execution.
  • Because PwC views architecture as the design of the business and applies an operating framework to business.
  • Usually, the client says, “I have a problem and I need help.”
  • Clients often have problems in three broad categories, see slide 10.

OFFICE OF ARCHITECT

The value from a mature architecture organization is shown on slide 11.

Enterprise architecture is both a noun and a verb. There’s a process (verb) of creating an architecture organization. Enterprise architecture is also the noun due to the things used, such as blueprints.

“A mature office of the architect adds value by more effectively managing complexity and risk in the ‘big picture.’ ”

Mature architecture organization bridges execution to organizational strategy.

In maturing an architecture organization, the framework that this talk addresses is only Phase 1. This framework is “just to get you started.”

The term framework refers to the set of artifacts used to engage with their various clients. Their framework is made of four facets:

  1. Architecture organization
  2. Architecture service catalog
  3. Architecture service delivery management
  4. Architecture governance

A typical architecture organization (office of the architect) provides the service catalog, as visualized on slide 17.

ROLLOUT APPROACH

These are some ideas for how to mature your architecture organization:

  1. Document and assess existing EA practice. Understand your context, the environment you’re in, stakeholders’ requirements, and the skills and competencies you have.
  2. Develop a target operating model. Include principles, value, mission, services to focus on, metrics to collect, and a report out to show value.
  3. Lay out a roadmap and business case. It’s important that you communicate the case for change to your stakeholders. You don’t live in a vacuum.

MAKING CHANGE STICK

Key insights:

A centralized team of architects is critical in driving EA standards and approaches. You need a centralized group. It does not need to be a large group. It just must not be in the weeds all the time. Must think strategically.

Architects should be assigned to projects as core-team members, for roughly 60% of their time. Feedback loop that keeps them grounded and builds credibility with other stakeholders.

EA leadership requires strong management. The leader must be marketing and selling architects’ value to the stakeholders. Good work does not speak for itself (in most organizations).

EA is not always the best name for communicating. PwC started using “design.”

With regard to factors for making change stick, there is an internal focus. But there is also a broader context you must be aware of. Make sure you know what’s needed. What does that mean? One example: If the organization is tactical and operates quarterly, they are less interested in reference architectures as opposed to specific project architectures.

Communicate, Communicate, Communicate. You must have a communication plan.

Presentation link: http://resources.sei.cmu.edu/asset_files/Presentation/2014_017_101_89568.pdf

Software Architecture Community of Practice at Raytheon
Sunitha Vallabhaneni, Raytheon Intelligence
Doug Dusseau, Raytheon
Keith Nolan, Raytheon

Sunitha Vallabhaneni is an architect working on product lines.

Raytheon is one of only four companies in the world accredited by the Open Group.

Raytheon RCAP is the Raytheon Certified Architect Program. It is a company-wide initiative founded in January 2004 and spans all businesses within Raytheon. Only Raytheon employees can participate; it is for senior system and enterprise architects. The RCAP is a rigorous process following 34 different courses.

Raytheon SwAP is the Raytheon Software Architecture Program. It is a corresponding program for software architects that was founded in October 2011. The typical student has 5 to 15 years of experience. SwAP has three courses in common with RCAP.

Goals: Improve program quality; enhance collaboration and reuse; develop and enhance skills of software architects.

SwAP program structure follows three phases: Foundational > Core > Domain Specific (optional). All participants must take the foundational and core courses. The domain-specific courses cover topics such as cloud computing, real-time embedded systems, and service-oriented architecture.

Capabilities of SwAP graduates

  • Leadership of software architecture activities – A standardized approach that software architects own and take leadership over; care about quality attributes as well as functional requirement
  • Leadership of software architecture teams – understanding and following governance/decision-making models; important for architects to know the customer
  • Understand important architecture trends and technologies – Follow ISO 42010 standard
  • Understand established software architecture patterns, strategies, and tactics
  • Understand Raytheon’s architecture enablers and assets
  • Improve collaboration ability – share best practices, tailored approaches, and reusable assets

Collaboration enablers: a variety of items, including TIG’s, technology interest groups; Raytheon ACT, an architecture collaboration tool; and RSpace Communities of Practice (CoPs).

Community of Practice objectives

  • Improve communication
  • Improve general knowledge at Raytheon of software architecture principles and practices
  • Bridge gap between business and software teams
  • Help programs be more successful by leveraging a pool of experienced software architects. Many software architects who have been through a standardized program can communicate more efficiently.
  • Help coordinate architecturally relevant concerns across functional organizations

Community of Practice organization

  • Start with a kickoff meeting.
  • Have monthly meetings with co-chairs.
  • Use communication tools, such as Lotus Notes mailing group.

Past presentation topics: design patterns, product-line architecture, and leadership and software skills for architects (including how to get buy-in from the customer).

CoPs are organized along business units mostly due to location. The individual CoPs do collaborate with each other, providing cross-unit communication.

Lessons Learned

  • Self-organized CoPs are more effective.
  • The community helps select topics but co-chairs filter them.
  • Co-chairs keep CoPs active each month.

Presentation link: http://resources.sei.cmu.edu/asset_files/Presentation/2014_017_101_90448.pdf

Growing an Architecture Community of Practice
Mark Stofferahn, Travelers Insurance

Lead Architect in the Business Insurance Division of Travelers. Today he will describe what Travelers is doing to guide architects across the enterprise.

The following are approaches for fostering a CoP through communicating architecture and developing architects.

Some points about Travelers:

  • Second largest writer of commercial U.S. property casualty insurance
  • Largest writer of workman’s comp insurance in the United States.
  • In the Fortune 500 and a component of the Dow Jones Industrial Average
  • Approximately 30,000 employees
  • Have a separate enterprise architecture team

BI Enterprise Architecture Community

  • Discipline architects
  • Portfolio architects
  • Domain architects
  • Solution architects (mostly members of project teams)

What were the issues due to all these organizations?

  • Siloed project teams
  • Duplicated effort
  • Communication based on “who you know” and the “sneakernet”
  • Creative architectures
  • Performance issues, systems that don’t integrate, open-source software in use with no support, and some legal issues

Who actually goes and talks with peers about architecture?

These issues led to the need to start a CoP. The idea was to simply sit down with peers and talk about some things with other architects. They began with about a dozen people by just putting an appointment on the calendar. Later, they moved to more structure and started having monthly presentations. Topics included technologies, standards, guidelines, and best practices for not reinventing the wheel. Meetings made heavy use of web/video conferencing to unite geographically distributed architects.

The CoP gives domain architects the opportunity for immediate feedback on draft standards. Also, members share project experiences, methodologies, successes, and failures. Topics have also included reference architectures and quality attributes of various architectures.

Travelers now has over 100 members across the enterprise, with 30 to 40 on the call each month. Stofferahn maintains the mailing list, brainstorms/researches presentation topics, schedules, develops the agenda, takes notes during the meeting and publishes them to a SharePoint site, and sends thank you notes to presenters and managers after the meeting. He believes this follow-through is what drives community engagement.

How do they reach out to the broader IT community?

  • Host monthly “Lunch & Learn” sessions.
  • About 45-minute presentations with 30 minutes of talk and 15 minutes of questions. Provide only quick overviews of technical topics.
  • Examples: implementing security in JEE; best practices for web page scripting.
  • Are attended by project managers, architects, and DevOps.

How do they communicate what they do for the enterprise?

  • Held an “open house.”
  • Gave their own internal architecture conference.
  • Had multiple presentation tracks organized along solution architecture, domain architecture, etc.
  • Had booths and demonstrations. Example booths: governance process for architecture, set of artifacts for architecture, and a working application in the booth demonstrating an implementation.
  • No swag.
  • Business presentations, each about 20 minutes long, covering security, big data, cloud architectures, etc.

Now Travelers has CoPs, Lunch & Learn’s, and open houses.

What’s next?

How do they develop architects? This is the next question, and they are in the pilot stage.

  • Develop a baseline set of skills common to all types of architects. Based on standard skills: business, technical, communication, and leadership.
  • Create career paths for how to move into architect roles.
  • Include a mix of purchased and developed-in-house training.
  • Provide mentorship by pairing senior members with architects.

What has been the impact?

  • From management’s perspective:
  • At open house, they see the interest from developers and others in the booths
  • They hear of the communication going on in the mailing list and calls.
  • From project teams, they know where to find architects they can talk to.
  • From developers, the company is elevating quality of architecture in general and therefore improving developer experience.

 

Advertisements

2 responses to “SATURN 2014 Building a Community of Practice Session (notes)

  1. Thank you nice job of summarizing.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s