Edit me

What Is Community

The BTABoK uses the term community to refer to a group of architects, extended team members, internal and external to an organization who must work together to deliver the best business and technology strategy possible. The community is the binding agent between them, which some might call a center of excellence or professionalism or other terms.

The goal of an architecture community is to increase the overall architecture capability which impact their shared context, scope and coverage as well as to achieve the goals that they set for themselves and the organization.  

In addition, community is the center of excellence in professional practice, including both the internal community as well as the external community of architects.

Why is Community Important

The BTABoK uses the term community to refer to more than a loose-knit group of people but more in terms of the living body of professionals within and connected to an organization (including the vendors and service providers).  

BTABoK Tenets

The following tenets can describe the basic approach to community throughout the BTABoK.

Community Eats Framework for Lunch

The BTABoK is based on a true professional model for architecture practice. This model relies primarily on the process for developing quality people who are fully accountable for their work as opposed to following a framework or process. Community is the backbone of the organizations ability to deliver the full architect capability.

Specialization-Based Conflict Destroys Practices

To advance an architecture practice those with the title of architect, and those that identify with the practice (whether titled or untitled) must work together to create a working engagement modelor risk losing the value of the practice overall. This risk is associated with the use of the term architecture and its recognition within the stakeholder community and the strategy of the organization. For example if business architects are disconnected or at odds with software or solution architects, it creates a break in the value streamarchitecture necessary to deliver on the primary purpose of the overall architecture practice. In addition, stakeholders become confused when so many definitions and nuances are provided to them on the overall value, purpose and mission of the architecture practice. In many cases, this confusion may grow to an overall discontent with the practice or worse a belief that the architecture practice does not deliver value in some or all of its parts.

Communities Define Architecture

As a positive extension of the previous tenet, the community of architects (including the extended team) are the definition of architecture within an organization for good or bad. The community includes then all practitioners regardless of specialization, scope of impact or domain area, as well as the extended team(those practicing architecture without the title) and any vendor or services staff influencing the internal organization stakeholders. If this community is effective in modeling their engagement model, providing a working definition of the practice, enhances their personal competencies, and effectively manages their stakeholder community, architecture in itself will be seen as valuable to the organization. The primary challenge to value recognition comes from within the practice, not without.

Get Proactive in Your Value

The value proposition of an architecture community is difficult to quantify explicitly and objectively. There are three major components that the community can use to drive its value proposition. These are critical components that will drastically change how the organization views architecture.

1. Use the stakeholder driven approach from the BTABoK. Value is perception. What is believed by the organization is the truth, regardless of its veracity. On average there are 3-5 stakeholders per architect within a company who are deeply important to the architecture practice, with much overlap. If these stakeholders perceive the team as valuable, the team will be considered valuable. Don’t be reactive, be proactive. Use the tools provided to divvy them up and make a difference in their jobs. It works every time.
2. Create goals that are innovative and ownership-based as opposed to governance focused and consultative. The goals of a valuable practice should focus on what value is delivered and to which stakeholder and how it is measured. Reuse, cost-reduction, and risk-aversion are focused on enterprise stability. Innovation is based on new business, higher returns, new customers, successful missions, faster service, etc. Ownership-based goals are focused on delivery not design. How many successful outcomes did each member, or member team create from the practice?
3. Get explicit about the engagement model. Understand that engagement is about how the architects view the practice and how they choose to deliver services. If every architect in the company is involved and approves of the engagement model, they will implement it and live it. This reduces the arguments, disagreements and friction in delivering value. Do not wait for the chief architect to decide the approach. A professional practice includes the explicit, not implicit, agreement from the participants. The approach below to creating an engagement steering committee comprised of all types and levels of architects will help with that.

Community Approach

The BTABoK uses the term community to refer to a rigorous practice model which mimics in some ways professional models used by doctors, building architects and other knowledge and competency based professions. The approach the organization uses to

Communities of Practice and Centers of Excellence

Instead of using just the term community, the organization should think of it as a Community of Practice or even a Center of Excellence. The development of the community in this way will lead to significantly higher degree of communication and shared knowledge as well as a sense of responsibility and shared goals across the team.

Structuring the Community to Achieve Results

There are two sides to structuring the architect community; a) organization reporting, and b) role and practice leadership. Organization reporting or management structure are sometimes out of the hands of the architects to decide until the practice has developed enough support and maturity to influence such things. Practice implementation related to roles, mentoring, engagement definitions and other achievement based leadership, can be implemented based on a simple community of practice or can extend to a full center of excellence. However it needs to be noted that any such system of seniority cannot be based on years of experience but only on demonstrated excellence in competencies and value results which in general are very different things. For, example take an architect who has had the title for many years at a less mature organization because she/he has had the influence to ask for the title. They may have the years of experience but may not have been challenged during many of them on critical aspects of the competency and skills model. It is essential then that these individuals realize that competency is the only demarcation between ‘senior’ architects and ‘junior’ architects. No matter how many years as a developer, an individual may have no skills in business technology strategy. This will also guide mentoring and role allocation at least within the architect profession. If needed these roles can be weeded out by having individuals pass the Iasa CITA-P/D which are experience based certifications.

Specializations and Community Conflict

Specialization activities and roles need to be dealt with early during the engagement model as conflicts most often arise between those of different specializations. It may be helpful to think of the specializations in medicine to understand the differences and why in-fighting can be so dangerous to a practice. Surgeons and General Practitioners or doctors working in an ER often have very different views of the world and yet both are considered doctors. This distinction will help design a working practice in architecture where business architects and solution or software architects can work effectively together.

Question 1: Does the Practice Need Specialists?

Often small practices, solution architects and enterprise architects will have the equivalent of general practitioners, those that know enough business, information, infrastructure, software and solution architecture to succeed with average company products or projects.

In large teams or highly complex domains specialization will exist and likely in larger numbers. Things like business model, product types, digital penetration into the industry will often help define whether the practice needs them or not. For example, how many business architects does a software product company need will likely be a very different answer than at a large bank. Use the architecture team canvas to help determine whether the current engagement model needs specialists or generalists and hire, train, mentor accordingly.

Question 2: How Are Specialists Assigned

The question of assignment is particularly difficult as having all architects everywhere is impossible. The assignment article provides detailed guidance and tools for assigning architects but specialists require specific attention. There is no use using a software architect to repurpose a data center if there are infrastructure architects available. Use the following to describe and assign architects based on specializations.

1. In general, solution architects focus on shared skills across the specializations. They are the go to for assignment for regular projects and should have the freedom to get hours from specialist as needed for the health of the product/project. They work with business architects to ensure the delivery of a value stream.
2. Large, complex, domain focused programs should be lead by a very senior specialist in that area. There are three axis to consider in this. One is specialization (the primary focus of ones competencies and experience), the second is domain focus (what medicine calls sub-specialization), for example an architect may be a software architect focusing on the retail domain with deep skills in mobile and web-based software. The third axis to consider in assignment is value to the business and the individual. Many architects will be passionate about a particular project. This motivation provides and extra layer of quality and benefit to the practice.
3. Be careful of assigning non-architects to lead architecture efforts because of their depth specialist skills. Architects must be based on the 5 pillars of competencies or their work will require direct architectural support.

The Extended Team: Mentoring and Leadership

The community of architects is only as good as its servant/leader capacity. Often called soft skills they can be the hardest to learn. Mentoring and leadership are practiced skills which should be taught and reviewed early on in an architects career. New architects often come from those in other professional areas like engineering, operations, and business with the right mentoring.

The architecture community should develop a leadership and mentoring program and understand the extended team extremely well. The ET article provides direct guidance in this area.

Implications for HR and Employment

HR alignment will need to be achieved over time. Career progression level for architects depend primarily on two primary factors; a) competencies and b) experience milestones.

Competency frameworks such as SFIA+ are used by many organizations to manage employees. However professions need to provide an adaptable competency model which HR professionals can include in their job models and career progression. Competency growth is especially difficult for professions where demonstration of excellence is necessary to progress. The competencies are also generic in the BTABoK so they can be adapted to many technology environments. The BTABoK provides both a competency framework as well as default job descriptions which are aligned with learning and growth throughout an architects career.

Experience milestones should be modeled after professional association certifications which provide the expertise to distinguish between those that can deliver at the degree necessary for the next phase of the professionals career. It is best to align these certifications to growing to the next level even in large internal organizations.

Implementing a Community Driven Architecture Program

The Engagement Model Steering Committee (Large Teams)

The engagement model should be managed by a cross-section of ALL architects

• If there is no common reporting structure then manage by vote
• This should include customer or service facing architects as well
• The group defines how the entire architect organization
• Engages with the business
• Measures itself for success
• Grows it’s value and capability across the enterprise

BTABoK 3.0 by IASA is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License. Based on a work at https://btabok.iasaglobal.org/