Choosing a framework to get started with can be critical to starting a successful architecture practice. Factors going into the choice come directly from the culture and derives value for a company. Taking this approach to understand the value of the program can help to keep it being a side of desk project or a practice which solely becomes an ivory tower exercise. For example, a financial institution should probably not leverage FEAF, as it is geared towards a government application. Similarly, a dev-ops software startup would probably not want to leverage something as comprehensive as the TOGAF model due to the size and complexity of the implementation. That brings me to another point about size of the organization. Often, architecture is used as a buzz word in smaller organizations, although a full-on practice would have no place. In this case leveraging the Zachman model provide guidance would yield some foundation insights into the business and provide a SWOT style analysis. It’s definitely not one size fits all.
Once the initial framework begins providing guidance for the practice, low lying fruit such as creating a glossary for the organization determines how to change the practice further and derive more value. The idea of a glossary becomes the foundation for other activities, such as creating artifacts (ie. RACI, Designs). Once these key artifacts can be created it is now up to the Chief Architect to discover the areas of change that get put towards a road map. These artifacts and control of priorities are easiest to control as a central group.
Contrary to centralization, we can see some organizations embrace a federated model. There are distinct advantages to a change like this one. A new found agility would be realized through federation. Not only with solutions delivery but also going forward each line of business would have an embedded architecture group. This can help to drive innovation and isolate value brought to each federated unit. A centralized group would still exist but could be used for technical trials, POCs and other non-value add activities while the business executes on their time-to-market strategies.
In conclusion, Federation is not a good thing or bad thing, but transforms the business. Aligning the governance model together with getting things done benefits the business, driving innovation and affording the federated teams to avoid the quorum of architecture review.
[1] Anne Lapkin, (November 2004), Gartner: Architecture Frameworks: How to Choose, Periodical no. G00124230
I once worked in a large organization (200 architects) that had central architecture teams when I first started. We had 3 centralized architecture teams separated by architecture domain; business architecture, data architecture and technology architecture. In contrast, we had solution architecture teams that were aligned to business units. For example, Finance solution architects, Human Resources solution architects, etc…
At one point, I suppose our Chief Architect felt that the central business architecture team was a little too central because he had them align to the business units as well. That way the business architects could go deep with their knowledge of their business unit's operation just as the solution architects did.
At the same time, the senior architect managers 2 management levels up served as central enterprise architects. They could provide a perspective across the value streams.
I agree with your assertion that frameworks are definitely not a one size fits all proposition. I think what some people miss in terms of architecture is when to start. The idea of having an Enterprise Architecture program isn't valid for every organization. Organizations of smaller size, limited technical diversity, a need to be nimble, and sensitive budgets wouldn't necessarily need a program at all. For them leveraging any type of architecture framework might be overkill. A set of guiding principles and a structured acquisition process might help that organization far better. I think more organizations should evaluate simple steps before looking at frameworks.