This is the beginning of the journey to developing a flourishing professional body. Since it is the Association of rather than for Open Group Enterprise Architects, its success is going to be mostly down to the members.
To start out, we have announced the AOGEA and opened it up to membership now, even though the launch is scheduled for the beginning of February 2007 at the Open Group conference and Member Meeting, if for no other reason than we might not have everything right and we can use that time to get your feedback on improvement points……. don’t wait to be asked.
We also need to start getting you engaged as soon as possible. There is much to be done. Although The Open Group members are responsible for TOGAF and for programs such as ITAC there is a lot more that needs to get done. For example, if we are going to develop a real profession we need to develop a code of ethics and a process for policing them. This is a something for an AOGEA Work Group …….
We will also need to have special interest groups. These might be industry specific or subject specific. And we will need Chapters, for local networking among AOGEA members.
This could be very exciting. If you would like to start a Work Group, SIG or a Chapter or just get involved, let me know………
Finally we will have a Bulletin Board where members can post questions and hopefully other members can give them some help.
I don’t want to shut off discussion of my last post, but I noted there that another of my open questions about enterprise architecture is:
“Is it possible for someone to be a competent architect without any experience as a practitioner in the implementation medium of the architectures he/she develops?”
Let me state at the outset that my answer to this question is almost always ”no”, and that this is an “informed hunch”, based on my personal experience, but I have no actual data.
The whole point of architecture is to make it possible to make things that are fit for purpose. If it is not possible in some practical sense to make the thing for which an architect has created an architecture, that architecture is useless. Architects cannot simply “throw an architecture over the wall” and insist that its implementation is entirely someone else’s problem. If an architect hands off responsibility for implementation to someone else, it has to be with the assurance that implementation is not only possible but practical.
So the question then becomes “how can an architect be confident that an architecture can be implemented?”
If it’s not based on firsthand knowledge of and experience with the implementation technology, can it be based on secondhand knowledge and experience? Can it be based on education?
Architects can’t be expected to know everything, or have firsthand experience with every implementation technology they might encounter. And while there are many lessons about implementation pitfalls that are largely technology independent, there are too many that are technology specific. Architects can avoid falling into these traps by knowing how to take advantage of others’ knowledge and experience, in particular by asking the right kinds of questions of ”subject matter experts”. My experience has been that the ability to do so is greatly dependent upon having had some kind of implementation experience, and the more and various the better.
Can someone who has no implementation experience of any kind be taught how to avoid specifying an architecture that can’t be implemented? I don’t mean no experience making things; I mean no experience making something that has been architecturally specified, or, more importantly, no experience working with the implementers of their architectures.
There’s a reason many experienced architects disparage theoretical or “ivory tower” architects. It’s because they share the sense that there’s no better way to learn how and why to avoid screwing something up than having screwed something up yourself. It’s why we ask candidate architects what they learned from an engagement, and what they would have done differently. Good architects recognize and exploit patterns, and the best architects recognize and exploit the most general patterns. We can teach people patterns (in this case, patterns of failure), but consistently successful recognition and exploitation (i.e. mastery) requires practice, as we explored in the discussion of my last post, and practice means firsthand experience.
There’s increasing interest in developing a university curriculum for educating enterprise architects, and it’s inevitable when talking with academics that questions about possible research topics come up.
Last year I gave a talk on “Open Questions about Enterprise Architecture and the Enterprise Architecture Profession” at The Open Group’s Enterprise Architecture Practitioners Conference in San Francisco (28 – 30 January 2008) and at the Enterprise Architecture and Integration Summit in Calgary Canada (11 – 12 May 2008). A year later, these questions remain unanswered, at least authoritatively. We need data, but all we have is opinions, so I’m hoping this item will provoke some suggestions as to how to get some real data, but I’ll settle for more discussion about what we think the answers might be, especially if it includes some justification.
Of the eleven questions I asked in those talks, I’m going to focus on one of them, and next time, some closely related questions.
The way I originally asked the question was
“Are enterprise architects born or made?”
This is a glib way of asking
“Is there an aptitude for enterprise architecture?”
The related questions are:
“If there is an aptitude for enterprise architecture, how do we recognize it?”
“What, if any, (possibly other) critical success factors are necessary to develop competent new enterprise architects?”
“Is it possible for someone to be a competent architect without any experience as a practitioner in the implementation medium of the architectures he/she develops?”
Two recent books have dealt with the general question of how aptitude relates to success. The central thesis of the more popular of the two, Malcolm Gladwell’s “Outliers” (Little, Brown), is that circumstance has more to do with success than ambition or aptitude. Regarding the extent to which aptitude contributes, Gladwell cites the “10000 hour rule”, the observation that the only thing clearly distinguishing the top performers in any discipline is that they have accumulated at least 10000 hours of “deliberate practice”, i.e., practice that is specifically targeted at addressing their performance deficiencies (”The Role of Deliberate Practice in The Acquisition of Expert Performance” by K. Anders Ericsson et al., Psychological Review, Vol. 100 No. 3, 1993). The other book, “Talent is Overrated”, by Geoff Colvin (Portfolio), adopts the 10000 hour rule as its central thesis, that talent or aptitude is an intuitive idea that is not supported by the evidence. Colvin does concede in his final chapter that aptitude or predisposition might provide a small but significant initial difference that is amplified into a big difference by the 10000 hours of deliberate practice, but he relies a lot on the failure of early performance to predict ultimate success (citing, for example, “child prodigies”) to make his case.
Reading these books, I wondered what role innate ability, aptitude or predisposition might play in determining the maximum level of performance one might achieve; neither Gladwell nor Colvin address this question, and it remains an open question as to what motivates an individual to make the often Herculean effort necessary to acquire 10000 hours of deliberate practice.
It is certainly the intuition among most practicing enterprise architects that I have talked to that there is a certain mindset that seems to characterize the best architects, and there does seem to be a lot of anecdotal evidence that IT and enterprise architects tend to be in the INTJ and INFP Myers-Briggs categories.
Be that as it may, how might aspiring enterprise architects acquire the requisite 10000 hours of deliberate practice, given that this is practice in the etude sense, targeted at the practitioner’s deficiencies, not practice in the professional sense, driven by the client’s needs.
So, what do you think? Is there an architectural aptitude? How might academic researchers confirm or deny such a hypothesis? Is there something different about architecture that renders the 10000 hour rule inapplicable or irrelevant?
It’s that time of year once again. It’s the season for those time honored back-yard barbecues. In the US the barbe season starts around July 4th and goes straight through the end of August – culminating with my birthday party at the end of the summer - the most important summer barbecue event
Many of my neighbors and friends also have careers in Information Technology. It’s a good mix of folks ranging from line of business executives, IT executives, IT development directors and IT managers in both the commercial and the government sector.
I don’t know about you but I can only focus on small talk before I run out of things to say and end up staring at my feet in awkward silence. In order to keep the conversation going and avoid looking socially inept, I pick a topic of general interest that I pull out in case the conversation begins to wane.
This summer I have decided to focus on IT Outsourcing. In particular, I’m curious as to the status of those IT projects that have been outsourced to overseas firms. I was eager to learn from my back-yard barbecue buddies if they had been successful and what best practices they have learned. I was happy to find that my topic of choice generated lively discussions over the last two months over cold beer, hot dogs and watermelon – what more could I ask for? More importantly, I realized I was getting valuable feedback on a topic that is of interested to most of us in the IT industry – the effect of Globalization on our industries.
The primary question I asked each of my unwitting subjects was the status of their outsourced projects and if they intend to continue the trend and how their view of Outsourcing may have changed. Of particular interest to me (obviously) was how they were managing the design of their outsourced applications – the architecture. In addition, I asked my barbecue buddies what they think is the true value realized from IT Outsourcing - outside of potentially reduced costs. And for that matter – is IT Outsourcing really a cost saver?
So here are my top 10 observations from my unofficial survey.
Outsourcing works best for customizing commoditized elements of the IT infrastructure – the most used example was packaged applications like SAP and Oracle Financials.
Governance of the Outsourcing process is hard and requires full time focus. Interestingly, my executive sample cited managing to the time difference between the US and Outsourcing centers such as India and China as one of their organizations greatest challenges. One Sr. VP said – ‘work becomes a full time affair – eventually it took a toll on our people.’
The Outsourcing firms will do anything to get your business but once they have won the business they move the high value resources originally assigned to the account to the next business development opportunity. Constant oversight is necessary on behalf of the enterprise to ensure quality does not suffer.
As such most everyone mentioned that Outsourcing quality has started to suffer as more organizations leverage the practice and absorb the most skilled resources – and that stands to reason – chasing low cost labor is not a business strategy – as a result….
The costs have risen significantly for outsourced labor – one VP of a major IT security vendor suggested that he has moved from leveraging resources in India to those back in the US – by hiring US based college hires (programmers) his costs are almost equivalent to that of resources overseas.
Most financial organizations consider their It operations to be the root of their competitive edge and would only outsource those elements of their IT that do not expose their business logic.
Government agencies are prohibited from leveraging overseas Outsourcing or foreign owned integrators in fact recent government guidance is further restricting the use of foreign owned it vendors and integrators….however…
One government trend is localized Outsourcing– that is creating IT centers of excellence in low cost regions of the US. These locations are usually depressed markets like Southwest Virginia where some government contractors are lowering their costs by moving COE’s to this area.
The value proposition of Outsourcing tends to decline over time for projects of significant complexity and development length. As a result organizations are looking to outsource those efforts that have well defined milestones and can be effectively time-boxed. Consequently, large complex IT projects that are linked to new business strategies are being pulled back into the customer organization. Outsourcing the commoditized elements of these projects is still a common practice. However, the business analysis, the definition of the architecture, and the development of the core business processes are being pulled-back into the business or physically located closer to the home office.
And the most interesting observation I gleaned from my informal barbecue based survey was…..
I ended all of my discussions with a single question – ‘What is the real value of Outsourcing– outside of some cost reductions – what value was realized as the result of Outsourcing an IT development effort?” The answer was almost unanimous – The primary value to the business was realized as the result of rethinking the business. In other words, these organizations were forced to document their existing business processes and streamline the ‘to-be’ processes in order to effectively define the future business functions what would result form the outsourced IT system or application.
I thought this observation was enlightening. I began to ponder the implications – if the primary benefit realized resulted in re-architected, re-engineered business functions contained within an IT system, was Outsourcing the cause or the effect? Could a business not realize this same benefit if they leveraged an Enterprise Architecture and the skills of Certified IT Architects? Would the effective implementation of an evolutionary Enterprise Architecture strategy coupled with effective governance prevent an organizations business processes and IT systems from becoming stale. Because it appears to me the primary reason why these organizations embarked on an Outsourcing strategy in the first place (other than because it was trendy) was because their business processes had become stale and ultimately out of line with the business strategy. In my opinion Outsourcing is only triage for a dying patient if not leveraged properly – what businesses really need is to embrace a process of continuously rethinking the business from the inside out. The application of an effective Enterprise Architecture would help to prevent institutionalized resistance to change and the ability to more effectively respond to the changing business environment.
I recently gave a presentation at a CIO Summit, promoting the need for Enterprise Architects in general and for preferring professional grade members of the Association when hiring staff or contracting with service providers. The feedback suggests that the presentation was well received but I came away with a couple of impressions I would welcome your comments on.
First, it seems that the majority of CIO’s do not enjoy a relationship with the CEO where the latter sees IT in a positive way. IT seems to be perceived as something that holds back innovation rather than something that leads it. A part of the business where things can only go wrong, where the enterprise continues to pour money and where 80% of the budget is spent just keeping what they have going, rather than delivering any real benefit.
Second, less than a handful of CIO’s had heard of TOGAF (or any other industry standard frameworks for that matter) and even fewer had heard of maturity models.
Third, the things that were top-of-mind in the people I spoke with were things such as the theft of credit card details of over 45million customers of the retail group, TK Maxx, compliance generally and staff issues, as well as pressure to reduce IT spend.
So, if this is the reality of your CIO’s world, staff issues excepted, we should be able to apply enterprise architecture to address these priorities. The challenge, I suspect, in many instances is overcoming the concerns that an EA effort will do no more than take people’s time away from other more pressing priorities, take a long time to produce anything at all and when it does will only tell us what we already knew. Now no one is going to say that as such. It is more likely going to be phrased in a sentence that includes those three little letters ROI.
So, in this environment, rather than trying to sell anyone on the idea of an EA effort to address the CIO’s issues, I would suggest picking one discrete subject, talk to the people involved in it and produce a brief report summarizing the situation and recommending some quick wins. You will most likely find that if there are problems or opportunities, that someone you talk to will know about them. This can be done with relatively little investment of anyone’s time and if there are no quick wins, you may still be able to ease the mind of the CIO on that subject. If there are, then don’t forget to give the majority of the credit to an EA approach, rather than taking it all for yourself or giving it all to the contributors to the study. Just make sure that the contributors get there fair share though.
Guidance on this approach can be found in the TOGAF Resource Base under the heading of Business Scenarios.
I would be interested in whether or not these are issues in your enterprise and what approaches you have used with success to promote the value of EA.
I would be interested to know how you deal with architecture governance in your enterprise, how well accepted it is and how effective it is.
In some places it is known as the “G” word and not spoken about. One person said that as soon as you introduce governance procedures, or mention the “G” word, you find that people are looking for ways around them. Others have said, that governance is no more than a power grab by a group that wants to take control. While others see it as not only necessary but also a matter of normal routine.
Growing up, in business terms, in the finance function of a large multi-national, I cannot recall ever hearing the “G” word. Instead we had internal control procedures, designed to protect the assets of the company. It all made sense at the time and still does. Authority schedules that described who could sign-off what at different levels, enabled the company to function without everything having to go through a single person or entity. Separation of duties meant that it took at least two people to mis-use the assets. Budgetary control enabled greater delegation of authority. And of course in a large enterprise, there is Internal Audit, who even in my day were focused mostly on auditing systems, leaving the real work to the external auditors.
Overall, internal control procedures not only protect the enterprise but also protect the individual when things go wrong. So, are the companies that have effective IT governance, simply extended these principles? I suspect the answer is yes. One thing that leads me to this conclusion is that ISACA who publish CoBIT has its roots in internal audit. So it is not surprising that CoBIT reads somewhat like an internal controls manual, which is a good thing, although it is wrapped up in scary words like the “G” word.
IT has always been an area where one person can make a significant change or have a significant impact without the checks and balances that are ever-present when money is directly involved. Yet today errors or mis-use, within the IT systems, can have devastating effects on more and more enterprises. On top of that there is more and more regulation, such as Sarbanes-Oxley, that require rigor when changing systems that have a direct relationship with the assets of the corporation.
In TOGAF 8, in the Resource Base, there is a section on Architecture Governance where the members of The Open Group have produced an Architecture Governance Framework and a piece on Key Success Factors. There is also a piece on architecture governance and corporate politics that has obviously been borne out of similar experiences by a number of members, when it says, “An enterprise architecture imposed without appropriate political backing is bound to fail. In order to succeed, the enterprise architecture must … ”
Which takes me back to the original question, how do you deal with architecture governance in your enterprise, how well accepted is it and how effective is it?
The San Francisco Chronicle caught my eye recently with a headline: “Bad behavior in the blogosphere” The sub-heading was “Vitriolic comments aimed at tech writer make some worry about downside of anonymity”
It always disappoints me when I see flame mails or criticism or comments of a personal nature. I know we have Netiquette but not everyone does, or if they do, they do not always abide by it. If we are to raise the level of professionalism among Enterprise Architects then this is certainly a subject that falls under the heading of professional etiquette and needs to be eliminated. Tim O’Reilly, the publisher, was quoted as saying, “We need to say this is not acceptable behavior”. In a professional association, such behavior should meet with appropriate disciplinary action.
In this particular case, the so called, “vitriolic comments” were much worse than at first appeared as revealed in the first paragraph. “Death threats against a popular blogger this week have ignited an online firestorm about free speech, civility and sexism on the Internet.”
The Economist published a special report entitled “The battle for brainpower” in its October 7th-13th, 2006 issue. It is well worth reading in full, not so much because it tells us anything we didn’t already know but more because of the way it presents what is occurring in this industry. That there is a shortage of talent, we have known for some time. One of our members told us some time ago that they are employing anyone that they suspect are or could be IT architects. One of the articles quotes the Corporate Executive Board when addressing the question, of what companies need to do to convince brainy people to work for them: that they need to focus on their “employment value proposition”. The article argues that the most important thing that companies can do to attract talented people is to boost their workers’ long term employability.
In professional firms (accountants, lawyers etc) this has always been the goal. Developing people is what fuels these industries. Trainees are brought in, trained and developed. Some stay as partners, others move into industry and development does not end once the trainees have gained their qualification. Continued professional development is a condition of retaining that qualification and professionals tend to seek out employment that will enable them to add new skills and experiences. The same desire for adding skills and experiences is not new to talented people in other disciplines, nor is it new that employers have needed to develop such people. One of the challenges though has been the lack of comparability between what can be learned in one organization or another, so it is unclear how portable the training is, which raises doubts as to the impact on the workers long term employability as a result of the track they are on.
When members of The Open Group started talking about their internal programs for IT Architects, there was a high degree of comparability, which made the consensus process for developing the IT Architect Certification program as an industry standard so much easier. So comparability can be achieved but more importantly the certification is a portable qualification, which clearly enhances the long term employability of those practitioners who achieve certification.
A flourishing professional body will not only be good for the individuals it will be good for the employers in so many ways, as has been proven with the traditional professions.
In The Open Group conference and member meeting in San Diego in January, I heard so many people recommend the book, “Enterprise Architecture as Strategy” that I wished I had been given a dollar each time.
A couple of weeks ago, we held our second Architecture Practitioners Conference in South Africa, where a couple of presentations struck me. The first was a case study of SARS (South African Revenue Service) who have exceeded all expectations in revenue collection recently. During that presentation, the CIO was quite dismissive of most architectural efforts. What they had done was to build a one-page picture of the operating model of SARS. This was then used as the basis for deciding where to prioritize effort and as a communication tool to everyone concerned. They claimed that it was so popular with the Commissioner that he would carry it around with him, use it to brief the President and use it to ask questions on progress and priorities.
The sub-title of the book is, “Creating a foundation for Business Execution”. As we know, “Execution” is the title of the Larry Bossidy (CEO Honeywell) best seller. The book talks of building the foundation in 3 parts:
Operating model
Enterprise Architecture
IT engagement model
It is the first of these that describes exactly what SARS have done.
The second was a presentation from SASOL (Oil and fuel) entitled, “How Strategic is Strategy”. In this the presenter took us through the evolution from Jim Collins book, “Good to Great” and its relationship of their vision, strategy, strategic focus areas, strategic goals and values of his company to the new focus on “Enterprise Architecture as Strategy”.
Since then, within The Open Group, we have developed a first draft of a one-page operating model, based on this book. It is a very powerful concept for communicating with both senior executives and technical staff. For us it provides a high level direction, a way of setting priorities and measuring progress. From it we can then work down to the enterprise architecture using the TOGAF Architecture Development Method (ADM) and on down to the models we need to describe the detailed architecture. Now we have a way of communicating at all levels within our particular enterprise.
Anyone that’s travelled on the London Underground (aka the Tube) will be familiar with the expression, “mind the gap”. Some might even have the t-shirt. This is such a problem that the London Undeground web site has a section titled “Tourist info”…. not “Tourist information” … “Tourist info” .. no wonder they complain about the standard of education in inner cities. Anyhow this “info” tells us that, “Many platforms are curved. This means that there is often a gap between the train and the platform. Please be careful to look out for any gap when you get on and off the train.” Not only that, but the issue is also embedded in the contract between London Undergound Limited (LUL) and its infrastructure provider who is required to, “provide LUL with train, station and related infrastructure in relation to the SSL Network as it may require during the Contract Period in order for LUL to operate, provide or procure the provision to the public of a modern and reliable metro service over the Underground Network in a safe, efficient and economic manner ……” Appendix 7B, Enhancement Requirements, under Section 3 Audible Requirements sub-bullet 3.4 states that, “The Automated Voice Announcer shall have the minimum functionality of automatically announcing information including: (i) when the Train doors are open at Stations where there is either a vertical or horizontal gap of six (6) inches or more between the Train step and the platform edge, giving the warning “Please mind the gap between the train and the platform”.
The architect, Charles Holden is accredited with architecture that was both functional and accessible. It was said that Holden embodied both the architecture of the modern and that of the past. A master of the traditional classical form with a profound knowledge of construction and materials. His modernity came from his belief that architecture should, ‘…throw off its mantle of deceits; its cornices, pilasters, mouldings…’ He was far more concerned with functional problems; how rainwater could naturally clean a wall; the flow of pedestrians through a building.
It seems that accessible like some other words has taken on a new meaning since the early 1900’s. Much of the tube is far from accessible by today’s meaning of the word. So, how did such an apparent pragmatist give us such a long-standing legacy that is quite dangerous to its users?
Well the answer is that, “these “gaps” occur, between relatively inflexible train and curved platform, whenever a line has to squirm to avoid going under an important set of foundations: as at Bank (station), where it was necessary to avoid the Bank of England.” Today, it just would not be allowed and an alternative solution would have to be found.
If we are allowed to use such analogies, the decisions we make in implementing Enterprise Architecture will involve trade-offs. Very often we have to deal with the reality of legacy applications that cannot just be replaced because they are inconvenient. Instead we have to design around them just as the architects of the tube had to design around existing foundations. For Holden and his boss Frank Pick, the managing director at the time, a few gaps were a relatively small price to pay. Although we make fun of the Tube now, in the 1930s the London Transport network of underground trains, buses and trams was regarded as the world’s most progressive public transport system and a role model of enlightened corporate patronage of contemporary art and design.
No doubt, the decisions were made easier because Pick and Holden made several foreign trips to investigate the modern architecture of Germany, the Netherlands, Denmark and Sweden. The chief characteristics of their British take on continental European modernism were sweeping curves with geometric detailing, exposed brickwork and concrete which, at the time, seemed daringly modern.
Allen Brown, President and Chief Executive Officer, The Open Group
There’s increasing interest in developing a university curriculum for educating enterprise architects, and it’s inevitable when talking with academics that questions about possible research topics come up.
