Why is it that some organizations have very talented architects, but they are not consistently successful producing architectures and systems? Isn’t it enough to have the best people working on these hard architecture problems? Maybe, but maybe not…
Architectures are developed by architects, but those architects work in teams, and those teams work within a larger organization or enterprise. Successful architectures require competence at all of these levels – architects designing and documenting, projects leveraging these architectures to support planning and governance, and enterprises enabling the architects to understand and influence the business strategy and goals.
The SATURN session on Architecture Competence considered these issues from three different perspectives.
Kenneth Kunkel, a Software Technical Specialist at IBM, presented “Architecting Your Organization”, which was all about how to avoid becoming a deer in the oncoming headlights, that is, how to architect yourself and your organization to be resilient in dealing with the sorts of problems that every project runs into.
Ken began with a call to action – the architect is a change-enabler within the organization, “making a triangle” between others who should know about each other but don’t, or who are competing and shouldn’t. He echoed John Zachman’s earlier comment that “technology doesn’t solve anything”, and we need to architect the organization to be able to apply the technology to create value. He challenged the architects in the room to become empowered, break down organizational silos, and become a leader of their community by building relationships. There were questions about one of Ken’s assertions, that organizations should be structured according to reusable services rather than complete applications – didn’t this risk increasing dependencies and coordination requirements? Ken agreed that you need to strike the right balance, but the decision should be intentional.
Robert Ellinger has had a long career at Northrop Grumman Corporation, including stints as a Chief Systems Engineer and Chief Software Architect. He took a contrarian view in his presentation “The Role and Development of an Enterprise Architect: A Devil’s Advocate Perspective”, asserting that enterprise architects are formed only through years of experience. While training and coursework is important, the skills can only be learned through practicing the disciplines of requirements analysis, system engineering, and system architecture. There were questions about how this career path could be achieved in an organization that did not own and perform the entire process from requirements through delivery – how could the necessary experience be acquired? Bob agreed that this could be a problem, and reminded us that his was a “devil’s advocate” position, intended to foster just that sort of discussion.
Finally, Shankar Khambhampaty, an enterprise architect at Satyam Computer Services Ltd., prepared a presentation on “Career Track for Architects in IT Service Provider Organizations”. (Unfortunately, Shankar was unable to present in person.) Shankar’s view is that architects are motivated by individual passions, recognition, and personal and professional growth. This growth is enabled by a clearly defined career track within the organization. Shankar proposed three career tracks – a Management Track culminating as Project Manager and Delivery Head, a Domain Track, starting as a business analyst and culminating as Head of Business Consultancy, and an Architect Track, starting as a developer and ending as Chief Architect. This Architect Track should be realized through job descriptions, clearly defined roles, recruitment, and performance review and recognition.
-John Klein, SEI