Making the Most of your Architects


Published on

Describes how to define the roles and competencies needed to be an effective enterprise architect inside an organisaiotn and how to position teams in that organisation. Delivered at the enterprise architecture conference (EAC) run by IIR in Las Vegas in 2007.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Making the Most of your Architects

  1. 1. Making the Most of Your Architects Making the Most of Your Architects EAC Las Vegas October 2007 Sally Bean Independent Consultant Weybridge, UK @ Sally Bean 2007 1
  2. 2. The ‘Brilliant’ Book Series: When will we see a book on Brilliant EA? 2 @ Sally Bean 2007
  3. 3. The path to EA maturity is a long and tough journey Extending the Domain May iterate or go backwards, especially if key players disappear or an inappropriate approach is chosen Implementing Experimenting Confused Aware/ Interested Achieving Value • Sustainable set of EA processes • Positive outcomes being achieved • Knowledge base being maintained • EA core team and community established • EA content is structured and managed • Relevance to other activities understood. • Stakeholders fully engaged • Pilot to establish potential value • Skilled and experienced advisors available • Learning orientation • Different people have different perceptions of what EA is • Lack of conviction and purpose • EA is competing for attention with other new ideas • A few individuals and champions trying to generate interest 3 @ Sally Bean 2007
  4. 4. There are many facets to an Enterprise Architecture effort Purpose Process Products People Plans Places Practice 4 @ Sally Bean 2007
  5. 5. This talk is primarily about People and Practice Purpose Process Products People Plans Places Practice 5 @ Sally Bean 2007
  6. 6. My experience • 25 years at British Airways – – – – 10 years spent doing various forms of EA Championed cross-departmental collaborative projects Worked on major programmes (e.g. new Heathrow terminal) Organised Architects’ community • 4 years as an EA consultant – EA frameworks for public sector clients (Zachman, MODAF) – EA team/skills development for 2 commercial clients – European EAC Conference Program Coordinator • Diploma in Systems Thinking (Open University) – Changed my perception of EA – Gained a useful toolkit 6 @ Sally Bean 2007
  7. 7. What I have learnt about EA • Every organization I have come across has a completely different approach to EA • EA is not a linear sequential process but a collection of loosely coupled activities • There is no recipe for successful EA - it must be tailored to the context and maturity of the organization • Significant EA value can be realised through improving interactions between people 7 @ Sally Bean 2007
  8. 8. Content of this talk • Vignette: What can we learn from the story of Walton Bridge? • Case Study: Defining Individual Architect Roles and Competencies • Creating Effective Architecture Teams • Conclusions 8 @ Sally Bean 2007
  9. 9. What does the story of Walton Bridge What does the story of Walton Bridge tell us about Enterprise Architecture? tell us about Enterprise Architecture? @ Sally Bean 2007 9
  10. 10. Walton Bridge has been in need of replacement since 1953 1750 – 1st Walton Bridge built Painted by Canaletto - ‘The most beautiful bridge in the world’ Unfortunately it decayed and only lasted until 1783 * River Thames, West London 1953 4th (temporary) bridge built. Weight restrictions successively decreased. 1999 this bridge declared unsafe for motor vehicles Temporary 5th Bridge designed to last 10 years, built alongside 4th bridge now used by pedestrians. 10 Severe @ Sally Bean 2007 congestion at road junction
  11. 11. 5 Options were considered for a bridge with a life of 100 years How mature, on a scale of 1-5, would you describe the architectural discipline of bridge-building? 11 @ Sally Bean 2007
  12. 12. Bridge Option 2 –Tied Arch was selected Stakeholders • • • • • • Factors considered: • • • • • • Road Traffic Congestion Pedestrians and Cyclists Opening up the River River Navigation Protecting the environment Road Safety @ Sally Bean 2007 • • • • Surrey County Council (SCC) Elmbridge Borough Council Spelthorne Borough Council Government Office for the South East Local residents Local businesses and organisations Road Haulage firms Pedestrians and Cyclists Archaeologists Etc…. 12
  13. 13. There’s more to the project than just the bridge Proposal incorporated Clover- leaf junction to reduce congestion. As this is ‘Green Belt’ Land, special Permission was required from Regional government Current Picnic area 13 @ Sally Bean 2007
  14. 14. Bridge Governance The bridge connects the Boroughs of Elmbridge and Spelthorne (both in Surrey) Surrey County Council is responsible for designing and building a new bridge Orders to enable access roads made by local authorities are dealt with by Government office for the South East 14 @ Sally Bean 2007
  15. 15. 4 Types of geographic jurisdiction are involved Central Government Regional Office County Council Borough Council • Government Office of SE • Surrey • Elmbridge, • Spelthorne 15 @ Sally Bean 2007
  16. 16. In reality, each ‘level’ of government has different responsibilities Central Government (Public Enquiries) Government Office of the South East (Compulsory purchase orders) Surrey County Council (Transport) Elmbridge Borough Council (Land Owner) Spelthorne Borough Council (Land Owner) 16 @ Sally Bean 2007
  17. 17. Timetable for new bridge Mar 2003 Sep 2003 Dec 2003 July 2004 March 2006 Nov 2006 Sept 2007 Public Consultation (3000 comments were received) Surrey County Council (SCC) chose the preferred Scheme SCC Submitted planning application More than 280 Objections were received Elmbridge BC submitted critical report and called for a Public Enquiry Planning Permission Granted to itself by SCC Public Enquiry held – focused on compulsory purchase orders rather than bridge design - Objections to these received from Elmbridge Borough council. Halfway through, discovered that completed arched bridge would be 20 feet higher than indicated by drawings Many adverse comments made about the consultation process Public Enquiry result announced – compulsory purchase orders rejected Revised Planning Application with revised junction layout. To 17 include permissionSally Bean 2007 life of temporary bridge. to extend @
  18. 18. What do the comments from local press say about the maturity of the planning process? ‘The bridge design has been approved by a majority in a properlyconducted consultation and will be an attractive landmark’ ‘Criticism was made of the bridge consultant’s five alternative designs, but we do not know the brief from which they started’ ‘The design of the bridge is utterly inadequate for such a key position’ ‘It does not attempt to address the serious traffic congestion on both sides of the bridge’ ‘Inevitably there is always a tradeoff between local concerns and wider strategic needs’ ‘It’s a very important site….it was painted by Canaletto’ ‘Considering that the population of Elmbridge and Spelthorne is some 210,000, it would appear that the 280 objectors are outnumbered by more than 750 to one’ ‘Some of the processes are dictated by the need to adhere to Governmentdictated timetables for funding’ ‘We must expect that any studies will be opposed by the more conservative members of the Walton Society…which I understand would prefer a ferry to any bridge’ 18 @ Sally Bean 2007
  19. 19. What can we learn about EA from this story? • You must manage hard and soft complexity – Every situation is different – Multiple stakeholders, perspectives and objectives – Rational and irrational opinions • Planning is a different kind of activity from engineering • Complex navigation of governance and decisionmaking • Boundary/interface issues can cripple the project • Local Knowledge is important • You will never be able to communicate enough 19 @ Sally Bean 2007
  20. 20. Case Studies: Case Studies: Defining Individual Architect Roles & Defining Individual Architect Roles & Competencies Competencies @ Sally Bean 2007 20
  21. 21. 2 Organizations • • • Global Pharmaceutical company Architecture function maturing, but needed Job Descriptions, Skills Development and Training Programmes 3 Separate Engagements, covering: – Project Architect Role – Enterprise Architect Role – Business Unit Architect Role • • • • • Utility Power Company Just beginning to recognise and define the role of the architect Up until this point, saw enterprise architect as infrastructure architect Establishing an architect community network Engagement to define a Competency Model for different types of architect 21 @ Sally Bean 2007
  22. 22. Case Study examples Similarities and Differences • Similarities • – EA seen as an IT activity – Initial driver was project quality, rather than ‘grand designs’ – Strong commitment to people development – Primary architecture focus on applications and infrastructure; relatively little focus on data and business – Architect roles and skills identified were broadly similar – Concern about ‘have we got the right people to do this’? – Had experienced significant M & A activity Differences – Maturity level – one relatively well into EA, the other only just starting – Degree of CIO engagement in architecture – Sourcing strategy – In one case there was a strong staff need for external professional validation of architect role 22 @ Sally Bean 2007
  23. 23. We looked at the context Purpose Process Products People Plans Places Practice 23 @ Sally Bean 2007
  24. 24. Key contextual questions PurposeWhat is the primary motivation for architecture? Do you have an ‘operating model’ for architecture Process Who do your architects interact with? Products What are the domains and outputs of architecture? People Plans Places What is your organisation’s Practiceapproach to learning and skills development? @ Sally Bean 2007 24
  25. 25. A similar approach was adopted in both cases Understand Context Understand Context Engage Stakeholders Engage Stakeholders External Best Practice Internal Competency Framework Internal Training Support • Architecture purpose, products & process • Practical Issues and needs • Working Group Define Roles Define Roles Define Competencies Define Competencies •Role Type descriptions •Job Templates •Competency model (Knowledge, skills, behaviours) •Blended learning programme Identify Learning Activities Identify Learning Activities Plan implementation Plan implementation 25 @ Sally Bean 2007
  26. 26. ROLES: In both cases we identified 3 distinct types of architect Enterprise Architect Project Architect Domain Architect Leads the development of architecture at enterprise or Business Unit level. Develops methods and frameworks for EA Accountable for overseeing projects to ensure they deliver models and solutions that fit with EA. Provides feedback on EA Expert in crafting reusable architectures related to a specific domain of expertise 26 @ Sally Bean 2007
  27. 27. We identified the most likely Architect Career Progressions Enterprise IS Strategist Architect Business Unit Architect (Company scope) (Business Unit Scope) Project Manager Business Analyst Domain Architect Project Architect (Technology or Application Scope) (Project Scope) Relationship Manager Customer Of IS Technical Non-Architect roles Lead Infrastructure Engineer Application Developer @ Sally Bean 2007 Common move Possible Move 27
  28. 28. We identified and grouped the competencies Competency Areas Competencies may be: Talents – innate abilities Skills – learned abilities Knowledge – relevant contextualised information General Competencies Leadership & Influencing Analysis & Consultancy Change Management Knowledge Development & Teamwork Observable behaviours Experience Organization Knowledge Business Knowledge IS/IT knowledge Organisation, people and decisionmaking context Architecture Competencies Enterprise Architecture Business Architecture Data Architecture Applications Architecture Integration Architecture Infrastructure Architecture Technical Leadership 28 @ Sally Bean 2007
  29. 29. Structure of competency model for Talents, Skills, and Knowledge Competency Area Competency 1 Competency 2 Etc… Competency Definition: Description of the competency Competency Definition: Description of the competency Competency 1: Description of the competency What you need What you need Learning Activities What you need What you need Learning Activities What you need What avoid Learning Activities to do to you need to do to avoid to do (talents and skills) to avoid (skills and knowledge) Behaviours that Counter-behaviours Books, websites, Behaviours that Counter-behaviours Books, websites, characterise the Behaviours that training courses Counter-behaviours Books, websites, and characterise the training courses and competency characterise the work-based and training coursesactivities competency work-based activities competency work-based activities 29 @ Sally Bean 2007
  30. 30. Example competency definition Competency Area: Analysis & Consultancy Competency: Creativity - The ability to generate valuable new ideas or to identify innovative approaches to solving problems Skills, knowledge and behaviour Things to avoid Learning Activities • • Books: De Bono: Serious creativity : using the power of lateral thinking to create new ideas Clegg and Birch: Instant creativity Websites: Work activity: Pick 2 creativity techniques and facilitate an ideas-generation and evaluation workshop with a small team Course: Creativity Techniques • • • • • Finds alternative ways of looking at a problem. Challenges assumptions and stretches boundaries Has a repertoire of techniques for generating and evaluating ideas Builds on existing or emerging ideas to create new ones Uses creativity techniques in a systematic way Creates an energetic atmosphere to stimulate creativity in others • • • Leaping to a solution because ‘it worked last time’ Rejecting apparently halfbaked ideas rather than looking for ways to make them better. Allowing deep expertise to blind you to better/different approaches Assuming the answer to a problem must be an IT solution 30 @ Sally Bean 2007
  31. 31. The desired competency profile varies by type of architect Excellent Good Competent Aware General Organization Knowledge Enterprise Architecture Business & Data Domain Architecture Technical Domain Architecture Competency Areas 31 @ Sally Bean 2007
  32. 32. A threshold level is required across all types for all roles Excellent If you don’t have a skill, you must know who does. Good Competent Aware General Organization Knowledge Enterprise Architecture Business & Data Domain Architecture Technical Domain Architecture Competency Areas 32 @ Sally Bean 2007
  33. 33. Domain architects typically concentrate on skills in one area e.g. technical Deep specialists may prefer to stay in one place Excellent Good Competent Aware General Organization Knowledge Enterprise Architecture Business & Data Domain Architecture Technical Domain Architecture Competency Areas 33 @ Sally Bean 2007
  34. 34. PAs have a broad level of expertise Excellent Good Good General skills for communicating and negotiating with clients and project team members and resolving tradeoffs Relies on Domain architects to fill specific gaps Understands how project fits into enterprise context Competent Aware General Organization Knowledge Enterprise Architecture Business & Data Domain Architecture Technical Domain Architecture Competency Areas 34 @ Sally Bean 2007
  35. 35. EAs are strong on general and business skills and have variable technical skills Excellent Local knowledge may be at more strategic level than PA Beware out of date technical knowledge and seek expertise where required Good Competent Aware General Organization Knowledge Enterprise Architecture Business & Data Domain Architecture Technical Domain Architecture Competency Areas 35 @ Sally Bean 2007
  36. 36. Principal Learning methods identified • External courses (classroom, distance learning) • Mentored e-learning • Community of Practice (CoP) – online and offline discussions • Shadowing • Action Learning • Briefings/Case Studies (e.g. lunch & learn) • Conferences, Seminars • Special Interest Groups 36 @ Sally Bean 2007
  37. 37. Creating Effective Architecture Teams Creating Effective Architecture Teams @ Sally Bean 2007 37
  38. 38. Key features of an effective team • A defined set of people (part-time or full-time) • Committed to a set of shared goals or performance targets • Complementary skills and knowledge • Recognised areas of interdependence which are supported by team communications methods • Ability for members to offer and seek support from each other 38 @ Sally Bean 2007
  39. 39. Architects might be in several teams at once • • • • • • Their formal work group A special interest group A cross-functional task team A Hit Squad Consultant to a management team Design authority to a development project team • Provides opportunities to build reputation as facilitator, boundary-spanner or methodologist 39 @ Sally Bean 2007
  40. 40. EA teams often draw a ‘3-tier’ organization model like this EA often starts in the ‘middle tier’ Internal Project Delivery Teams With Project Architects Business Unit Arch Groups Central EA Team 40 @ Sally Bean 2007
  41. 41. Organisational challenges of ‘3-tier ‘ EA • • • • EA Central teams can become remote from business EA teams are sometimes fragmented EA teams don’t always work as a team Small Business Units may struggle to gain critical mass in EA • Large Business Unit teams can dominate or undermine central EA team • Disagreement as to nature of role of Central EA • Disagreement on autonomy of Project teams with respect to architecture 41 @ Sally Bean 2007
  42. 42. The relative positioning of ‘Business’, ‘IT’ and ‘EA’ varies between organizations Example of different ‘mental maps’ ‘Lines of Business’ EA EA ‘IT’ EA IT as Supplier EA optimising IT IT as Partner EA as bridge IT and EA are ‘Pervasive’ disciplines with expert support 42 @ Sally Bean 2007
  43. 43. EA can contribute to a wide range of activities Problem-Solving & adaptive change Strategic Design & Planning Development Projects Business Strategy Business Arch IS Arch Technical Arch Operations & Monitoring People Process Applications Infrastructure Investment/Resource Management Process execution IT operations Performance monitoring Architecture Management Architecture Practice Architecture Products Business IT 43 @ Sally Bean 2007
  44. 44. The potential EA workload is daunting…how to balance it? Strategic Initiatives Strategic Enterprise Design & modelling Planning Business Strategy TechnologyArch Standards Business & Roadmaps IS Arch Technical Arch Problem-Solving & adaptive change Opportunity-spotting Troubleshooting Development Projects People Process Reviewing project Applications Designs & models Infrastructure Investment/Resource Application Portfolio rationalisation Management Shared service identification Operations & Monitoring Sequencing projects Process execution IT operations Infrastructure Performance monitoring rationalisation Architecture Maintaining a repository Management Architecture Practice Promoting Architecture Products use of EA content @ Sally Bean 2007 Business IT 44
  45. 45. Balancing the EA workload • Balance the team – ‘Techies’ and ‘Modellers’ – Bring in supplementary skills as needed (project management, communications) – Play to individual strengths using profiling techniques such as MyersBriggs and Belbin • Balance time spent – Task, – relationships (internal/external) – team learning • • • Don’t try to do everything. Identify areas of greatest leverage and focus on what is achievable Recognise that you only build influence and reputation through making valuable contributions Become masters of Time Management 45 @ Sally Bean 2007
  46. 46. Architecture Team Management • Architects can self-manage activities and workload • So what is the manager’s role? – – – – – – – – – Ensure compelling vision for EA exists Set clear priorities Get EA sponsors and funding Provide contextual information to team (e.g. political intelligence) Stop team getting bogged down in detail - get team to produce 80/20 results rather than strive for perfection Publicise team successes Champion architectural decisions and develop conflict strategies, Help team sharpen their communication Ensure continuity and sustainability of practice 46 @ Sally Bean 2007
  47. 47. Communities of Practice • Online and face-to-face interaction • Provide a forum to get questions answered, exchange ideas, and stretch each other’s thinking. • Moderated to stimulate debate and ensure quality interaction • Inclusive - encourage involvement by anyone with an interest in architecture • Not just a learning community but a network that makes things happen 47 @ Sally Bean 2007
  48. 48. Collaboration Matrix can help to clarify accountabilities Enterprise or Business Unit Level- may seek contribution from working level EA – Project Collaborate EA review essential Project Level: Strategic EA resource available only for major projects Primarily Business - IT may contribute Business-IT collaborate Primarily IT – Business may contribute 48 @ Sally Bean 2007
  49. 49. Architecture teams can facilitate organizational connections 49 @ Sally Bean 2007
  50. 50. An alternative metaphor for the enterprise? • • The BBC is a fascinating and wonderful organization that has produced some of the best broadcasting in the world, but it is sometimes very difficult to work out where its brain is… (John Sergeant Give me ten seconds, 2001) Is it possible to design ‘learning organisations that have the capacity to be as flexible, resilient and inventive as the functioning of the brain? Is it possible to distribute capacities for intelligence and control throughout an enterprise so that the system as a whole can self-organise and evolve along with emerging challenges? (Gareth Morgan, Images of Organization, 1997) 50 @ Sally Bean 2007
  51. 51. Brilliant EA? Blueprints and Brains Shared understanding of how things fit together Shared Interaction with blueprints of processes, information and technology 51 @ Sally Bean 2007
  52. 52. Questions? 52 @ Sally Bean 2007