An architecture is designed collaboratively. Architects are also, sometimes, part of the collaborative process. Yes, “also, sometimes, part of.” The collaborative nature of architecture in enterprises is what makes it so challenging, intriguing, and even vexing to those who are entangled in what is a very multidimensional process.

As business architecture gains more and more attention and adoption worldwide, every once in a while it can be useful to lift up, step back, and refresh on a few key concepts.  If you’re new to the discipline, these will help you to accelerate your understanding and navigate the wealth of information available.  If you’re experienced with the discipline, these will help you to ensure alignment with the latest and greatest evolution. This Advisor lays out the top five foundational things you need to know about business architecture.

In his on-demand webinar, “EA in the Face of Digital Disruption,” Cutter Consortium Senior Consultant Roger Evernden explored some of the issues enterprise architects are facing with digital disruption. He tackled how organizations and entire industries must rethink value — creating and capturing it ­— to meet the challenges that digital brings to our lives. In this Advisor, we share some of the questions addressed in the Q&A portion of the webinar.

Enterprises need access to data-driven insights faster than ever before. Analytics use cases have evolved from traditional, precanned reports to self-service and guided analytics. Enterprises exploring solutions to these challenges are steadily embracing the cloud data warehouse. These platforms provide agility, scalability, and simplicity that enable the enterprise to focus on data solutions rather than spending valuable effort on peripheral overheads.

My studies of enterprise architecture (EA) practices in multiple diverse organizations have identified several consistent patterns describing the size and structure of architecture functions that companies tend to find optimal for their needs. We can use these empirically observed generalities to synthesize a simple, heuristic three-step approach for designing organization-specific architecture functions.

We have typically found in the acquisition process that EA is primarily a technical capability and engaged in a constrained fashion. In most firms, the EA team does not possess the necessary critical business knowledge and, therefore, is not able to contribute to the acquisition process through direct engagement. At some pioneering firms, however, the reformation of EA has explicitly aimed to build a business strategy competence in the EA team by giving enterprise architect roles the responsibility for business and operations architectures.

Enterprises are expanding their API programs to include the broader concerns of enterprise architecture. In this Advisor, we describe some next steps for evolving your API platform.

Data is not a resource. Data is the breadcrumb trail of human activities. Like a true breadcrumb trail, it indicates the activity but never fully describes it. Data doesn’t fall out of the sky like manna from heaven; it cannot be mined like cobalt, either. Data is a residue of activity, and when you think about data in this way, you can envision a data management practice where you start to fully focus on the activities that bring you value and, therefore, the data you need to collect.