Enterprise Architecture has become a real container term; everyone uses it but means something slightly different. This confusion is not very constructive and certainly does not provide enterprise architecture with a positive image to other stakeholders. I therefore propose to reserve the term enterprise architecture only for the highest-level form of architecture; there where the organisation strategy needs to be made concrete. The enterprise architecture translates the organisation strategic goals into guiding architecture principes and change initiatives. The guiding principles express the most fundamental choices the organisation has made and that have an impact on the design of the organisation, in all its facets. Change initiatives are defined to move the organisation towards compliance to these principles. Top-level models show all facets of the organisation, from organisaction structure to IT infrastructure from a birds-eye view. They help position change initiatives and guide the design of the various aspect areas.
Given my definition of enterprise architecture, you probably wonder what other forms of architecture do not fall under the definition. One important form of architecture is reference architecture. This form of architecture provide architecture principles and models that are not specific to the organisation. Examples are industry specific architectures such as the IBM Insurance Application Architecture, or technical reference architectures such as the Microsoft Application Architecture for .NET. Ideally you just buy them off-the-shelf or select them from the public domain. In practice, reference architectures are not widespread, well-known or readily applicable (with a few good exceptions). This forces organisations to define their own reference architectures, based on what can be found in the market. What is needed is an adult market of reference architectures, that prevents us from inventing the wheel ourselves everytime over again. I see too many enterprise architectures that are mostly reference architectures; they contain a lot of generally applicable information.
Another important form of architecture is project architecture. This is where the enterprise architecture is translated into concrete projects that implement changes, mostly in the form of IT systems. The enterprise architecture and the reference architectures provides the project with principes that need to be implemented. Also, they provide the project with models that can be used for defining the scope, and the outline of the design of the project. The project architecture itself documents the high-level requirements, as well as the most fundamental choices that need to be made; the architecture decisions.
A form of architecture that is less well-known is what I would call the management of the architecture repository. This is basically configuration management of all aspects of the organisation, at a high (architecturally significant) level. This requires separate processes and responsibilities and ensures that the organisation knows its own installed base. Also, within the repository we can document the areas that need change, helping projects in making the proper changes. These changes can be determined based upon the enterprise architecture and reference architectures. The repository should help with impact analysis and propagate changes to all related elements. Based upon the repository we can generate architecture views that show specific elements that are needed in a specific situation. In my view managing the architecture repository is quite different from managing the enterprise architecture, and requires different skills and knowledge.
All these forms of architecture are not defined sequentially; they are defined iteratively and interactively. Iteratively because we must continually focus on what adds the most value. Also, the various forms of architecture influence each other. Interactively since architecture is a people's business; it is all about getting the most out of people and together find means to improve the business. An architect is not a specialist or hero that can do it all himself.
Comments (20)
Written by
This e-mail address is being protected from spam bots, you need JavaScript enabled to view it
on 10-05-2008 19:53
Dear Steven,
I agree with most of what you are saying. IT is an enabler for the business and can not be automatically translated from business goals. However, an enterprise depends on IT to do its business. IT constrains the business, can influence- or even determine it. Consider for example Internet companies such as Amazon; they solely exist because of IT. Also, IT can provide the business with competitive advantage if the IT of the competitor provides more constraints.
With respect to Enterprise Architecture I agree that in the past the focus has been on IT and the people involved have mostly been IT people. In my view that needs to change, so that the business adopts Enterprise Architecture as a means to attain its goals. I understand why you would call current EA practitioners IT-Enterprise Architects.
Written by
This e-mail address is being protected from spam bots, you need JavaScript enabled to view it
on 14-05-2008 22:27
Dear Danny,
Business will and can do business without IT, with the extreme exception of a business that is IT. If IT constrains a business doing its business IT will have to be changed because obviously IT-professionals did not create the right IT-solution. Comparable to the problem we have when we buy the wrong car, or office, or machine, or etc.
Yes, there are a number of companies that depend on one channel: internet. But they are stil normal companies, as Amazon proved when, nearly 10 years ago, sales went up and their logistics kept them from delivering what they promised. Amazon does not solely exist of IT. They have people, an extensive logistics process, financial processes and most of what other companies also have. Sure, they are only using an internet shop instead of one of stone and wood, but their business itself is not really limited by that. Megamarkt does the same business using a building, and they face comparable problems in their business. Of course with the exception of the specifics of the diffence in the channel they use: a building versus intenet. Megamarkt IS not a building like Amazon IS not internet. If you look at their business plan you may expect they will contain comparable issues, with the obvious differences.
I am not telling you IT is not important. I'm telling you IT is a means to realise solutions for business problems. If IT constrains a business, you may have the wrong IT-solution, or the solution may not be good enough. How does one determine what is good enough? Well, that is not an IT issue and that is why IT is not on strategy level. It's not basic, not for Megamarkt and not for Amazon. The fixation of Amazon on one channel - internet - is in fact a big business risk.... and opportunity.
Well, you are trying to redefine the term Enterprise Architecture to something it isn't. That is very confusing. With a dilemma: --- Enterprise architecture at the moment is IT-Enterprise architecture, a "thing" for IT-professionals. Wrong name for a "thing" IT-professionals really need to address the IT-landscape or application-landscape supporting an organisation (alignment issues). --- Organisations need to get their strategies translated into a working organisation. That is why they need corporate resources. IT is not a corporate resource. Calling this strategy translation Enterprise Architecture will make a homonym of the term. This is very bad for business, because nobody really knows what you mean if you use such a term.
My proposal would be: --- Let IT-professionals talk about IT-Enterprise architecture from now on to make very clear they are talking about IT in an organisation, where the scope of the IT-Enterprise Architecture will be tactical level at max. --- Let non-IT-professionals find another term for their view ( / architecture). The term business architecture is already contaminated, so what this term should be (if there should be one term for it): I'm not sure.
So we agree on a number of issues. The things separating IT-professionals from other professionals in this context are in my opinion: --- IT-Enterprise Architecture is not the strategic architecture of an organisation IT-professionals want it to be. --- IT is a means, a tool. Investment in and exploitation of this tool is to be at max at tactical level. Call it supply, where IT-professionals / IT-vendors (= softwarehouses, systemhouses, IT-consultancy agencies and IT-education) are working on solutions based on demand from the organisation. Demand and (IT-)supply will have to be strictly separated to get to at least acceptable results.
At the moment I see it is very difficult for IT-professionals to work at demand side in organisations. Everybody can change, but an IT-professional is and stays usually an IT-professional. IT-Enterprise Architects and IT-Architects are top-IT-professionals, supply side, with, if all is well, enough knowledge about demandside to create a fitting IT- or Application-landscape. Looking at the current installed base and the amount of IT-project that go wrong this is usually not the case. Let's make IT a profession before IT tries to dictate businesses what to do, and how to do it. The current conservatism of IT-professionals is mind-boggling for organisations and this is not a good prerequisite to annexate other areas of expertise.
Written by
This e-mail address is being protected from spam bots, you need JavaScript enabled to view it
on 18-05-2008 20:25
Dear Steven,
I understand your point with respect to the role of IT in an organisation and mostly agree. I also see why you call current EA practice IT-EA. We agree on that there is a form of architecture that folows strategy. I'd say "Enterprise Architecture" would be the most logical term here. I would expect most of the readers to agree. It does mean that current EA methods should pay more attention to the business side of things. Also, organisations should not treat EA as an IT exercise.
I would like to add that the main goal of my blog item was to clean up the term "Enterprise Architecture" with other forms of architecture: reference architecture, project architecture and architecture repository (architecture configuration management). I would like to get some response on that from others.
Written by
This e-mail address is being protected from spam bots, you need JavaScript enabled to view it
on 21-05-2008 21:59
Dear Danny,
One more reaction. And I do hope other reader are going to answer your question.
One remark left: The EA you mean is not what IT-professionals are doing, or ought to be doing. So it cannot be an extension to current EA methods etc., it is something else.
We did not talk about reference architecture, project architecture and architecture repository. Just one remark: look at the commonalities in the content of your four components. One of the pitfalls in IT is to separate what is in fact the same.
Written by
This e-mail address is being protected from spam bots, you need JavaScript enabled to view it
on 21-05-2008 12:58
Dear Steven,
Allow me to make some comments based on quotes from your posting dated 14-05-2008.
“--- IT is a means, a tool. Investment in and exploitation of this tool is to be at max at tactical level. Call it supply, where IT-professionals / IT-vendors (= softwarehouses, systemhouses, IT-consultancy agencies and IT-education) are working on solutions based on demand from the organisation. Demand and (IT-)supply will have to be strictly separated to get to at least acceptable results.”
IT is a tool, but information is not. Demand side is responsible for creating the information architecture. This is something that can not be left to IT vendors. And often overlooked by organizations.
“At the moment I see it is very difficult for IT-professionals to work at demand side in organisations. Everybody can change, but an IT-professional is and stays usually an IT-professional.”
This is a prejudice about IT professionals. Given the fact that most IT professionals started their career in a non-IT field, they should be able to take a non-IT view on matters. Your statement maybe true for those who were solely educated and trained on IT subjects. Unless they obtain non-IT knowledge and experience relevant to the demand side, they should refrain from trying to perform any activities in the enterprise architecture domain.
“IT-Enterprise Architects and IT-Architects are top-IT-professionals, supply side, with, if all is well, enough knowledge about demand side to create a fitting IT- or Application-landscape. “
Therefore I believe that only those IT professionals who actually worked on the demand side can perform the IT-(Enterprise) Architect role. Any IT professional with only work experience from the supply side is not enough qualified to have a deep understanding of the strategic issues of an organization.
“Looking at the current installed base and the amount of IT-project that go wrong this is usually not the case. Let's make IT a profession before IT tries to dictate businesses what to do, and how to do it. The current conservatism of IT-professionals is mind-boggling for organisations and this is not a good prerequisite to annexate other areas of expertise.”
In my observation most IT projects primarily fail because the demand side is focussed on the technology of the IT instead of creating an information architecture derived from the enterprise architecture (if such a thing exists!). Without a proper information architecture any successful solution is pure coincidence. Secondly the demand side fails frequently to implement the necessary governance in order for IT projects to design proper solutions for the information architecture. The conservatism you mention is likely a result of the inexperience of most IT professionals. There is no one really to blame, the IT domain is still in “a wild west settlement phase”. But I agree with you that is not a good prerequisite for annexation.
To conclude: if "enterprise architecture" is not a label for what an organization creates to describe themselves, IT should stop making references to EA. But my bet is that if you ask those non-IT people for a label, you will not get an answer. That doesn't mean there is something like an information architecture specific to an organization!
Written by
This e-mail address is being protected from spam bots, you need JavaScript enabled to view it
on 21-05-2008 22:05
Dear Steven,
My last response to your responses. IT professionals should not be in the lead in the ideal form of Enterprise Architecture I foresee. They should however be involved since IT is an indispensible part of an organisation. Also, in practice we do not live in the ideal world and IT professionals can lead the way.
With respect to your last statement I totally disagree; using one term as a synonym for different things only creates confusion.
Written by
This e-mail address is being protected from spam bots, you need JavaScript enabled to view it
on 22-05-2008 22:42
Dear Danny,
Well I don't know about IT being indispensible. Sure, at te moment. But tomorrow it will be quite different. Other means, maybe powered by some advanced form of IT, will become the means. We need food, entertainment, transportation etc. and the way we are going to get this, the means we use will differ when time evolves. Are we to call a car IT because it has a lot of hard- and software? I think we will start to "forget" about IT like we have "forgotten" about electric power and producing machines. They are indispensible also in todays world, but they do not determine our needs.
To be perfectly clear: I meant to say we will need a different term. That is why I like the change to the term IT-enterprise architecture, because talking about enterprise architecture suggests something that is wrong. Using the same term with 2 meanings, this is called a homonym, is very confusing and counterproductive. I thought that was what I said, but apparently I made a mistake. Sorry for the confusion.
Written by
This e-mail address is being protected from spam bots, you need JavaScript enabled to view it
on 23-05-2008 00:31
Dear Peter (sorry Danny),
Thank for your comments on my posting in Danny’s blog. Hope he does not mind if I answer you.
Comment 1: So: the term information architecture should be used in the organisation itself. This is why I often refer to remarks of Stephen Covey: knowledge of information puts the organisation in its strength thus enabling it to manage and control the means necessary to get the information they want, and need. You can’t outsource this knowledge. Good to know we agree.
Comment 2: Not really a prejudice, more a conclusion from 30-odd years of experience. You are right many IT-professionals started in a different field of expertise. If you know the half-life of knowledge is said to be 3 years at a certain point in time it becomes more difficult. What I really mean with IT-professional is someone who is working in and with IT as a profession. IT is in the core of this profession, and all else is seen in the light of IT. Of course somebody who is educated as a nuclear-scientist will be able to talk to other nuclear-scientists with ease. But still, if someone has been as IT-professional for, say, 20 years he/she will also look at nuclear-science from that angle. If only because in 20 years time a lot has changed and not kept up. Creating solutions to problems it is a great asset if you know your environment well. For an information scientist (term used in Groningen) or information specialist it may be an asset or a liability. Knowing what an organisation should say about its information is quite different from having to listen to what they actually say and put this in an architecture. Your last remark puzzles me “Unless IT-educated people obtain non-IT knowledge and experience relevant to the demand side, they should refrain from trying to perform any activities in the enterprise architecture domain”. Are you saying IT-educated people cannot be enterprise architects? And another. Enterprise Architecture is in fact IT-Enterprise architecture, as shown in practice. That is never demand side, always supply side. I use to call the architecture of the information at demand side the information architecture, but this term is redefined by the Americans and used as an alternative for application architecture or something like SOA. If I use my definition of information architecture you will hardly ever find IT-educated people there. There is hardly any education for information specialists or information scientist, but in my experience with hundred of people non-IT professionals have much less problems with it them IT-professionals. Because it is very close to their profession. So, creating an IT-solution as enterprise architect if quite different from creating the information view in the organisation. Supply versus demand. Different professionals, different people.
Comment 3: Well, working at demand side is quite different from the profession you have. There is only a very limited amount of work for an IT-professional at demandside. Simple reason: why should you have to think about the how when you are working on the what? Experience shows good knowledge of information at demand side, which involves between 20 and 25 subjects related to this information, can be stable for many years, and a basis to introduce new technology again and again. Talking about control over means like IT… And yes, a good IT-professional at supplyside knows about IT and enough about the “user” areas to create fitting and effective IT-solutions. The knowledge of information provides what is necessary at al relevant levels. That is why IT-professionals do not have to be above tactical level.
Comment 4: Yes, exactly. Technology is addressed at demand side. Even worse, I have been asked to help with a very large procurement and outsourcing where the customer was adamant to sent an IT-architecture to their suppliers and not the functional requirements: they were known in their organisation. Sure way to the next project disaster. Good to agree! The knowledge of information is never a part of the IT-enterprise architecture, and should not be. IT-enterprise architecture is an IT-issue, not a business issue at the moment. See my discussion with Danny. As I see information architecture, knowledge of information as a corporate resource, it is demandside, while IT-enterprise architecture is supply side. And yes: demandside does not implement the right governance. This is NOT IT-governance, but the governance/management of corporate resources at (sub-)strategic level. Next to the other corporate resources. Again: good to agree with you!
About blame. Well, currently IT is the anchor of organisations. Simple reason: change is too difficult and time consuming. Other reason: the professions in IT are not formed yet. We are still searching for these professions, and what people should do and know to be able to call themselves a member of that profession. Commerce, the IT-vendor community, is not helping because they know if they keep it gray they will earn a lot of money. Estimates show there ought to be somewhere between 40 en 60 different professions there. And yet another reason: what IT-professionals do and know slows things down nearly to a stop. A flagrant example, to take one of many, is the current introduction of something called principles. Everything is a principle, and we have to move mountains if a principle is not valid, or has to change. Talking about conservatism, and not only by rookies.
Comment of your conclusion: Enterprise Architecture is an IT issue, it is something IT-vendors are pushing keep in control and make money. That is why I applaud HP in their effort to change the term into IT-enterprise architecture. The real Enterprise Architecture, which is usually unknown as a concept, ought to be in the business itself and is about energy production and distribution, banking or selling food. I have experience with information architecture, my definition, for nearly 30 years. If you look at the data that is information for an organisation, you usually get somewhere around 3 to 12 concepts. No more, no less. Some are quite common, some are quite specific. If you talk about these concepts to strategic management, you do not have a discussion: they know. This is exactly why they do not really understand why the use of IT should be so difficult. Until you tell them in these terms what is happening, and usually they become annoyed or even really angry. Simple reason: why are there 5000 applications when you know you only have 4 or 5 kinds of information? In reality you tell them the IT is copying information around, creating a web of nearly the same, but just a bit different at tremendous cost. This is what you tell strategic management, the people that are in charge of demandside and unable to manage IT-supply. And if you have done this, try to talk to them about enterprise architecture principles. They will be tempted to shoot you..
Written by
This e-mail address is being protected from spam bots, you need JavaScript enabled to view it
on 23-05-2008 02:12
Dear Steven,
From your reply I sense that we agree almost on all points. Our differences are not fundamental. We had different experiences and therefor use different words or style to express the same thing. And I may have not expressed myself good enough. Sorry for some of the confusions in my wording.
About my profession (since you referred to it in comment 3): My education was in IT engineering: indeed an IT professional at tactical level. Until I got a job at the demand side advising the board and CIO how to deal with the IT infrastructure they needed, just like they need buildings, plants, cars, tools, etc to run the business. So work at the strategic level. This experience was an eye opener to me in respect to how the IT industry (vendors, suppliers, developers, consultants, analysts) operates. Some example are so bad, no one would believe me if I wrote them down. But I figure you know what I am talking about.
By the way: Bob Cringely wrote an interesting column last week on this subject: http://www.pbs.org/cringely/pulpit/2008/pulpit_20080516_004925.html
My clients (demand side) who I work with, call me IT architect. I use your definition of IT architect and therefor I don't consider myself an IT architect. So I tell them that I don't do the work of an IT architect. But they have a hard time understanding all these titles in the IT industry (no surprise to me), so many insist on calling me IT architect.
How should my work then be labeled? I figured that I advise clients on various matters and most of them are very closely related to what IT architects and IT engineers do and some respect to what information specialist do. I also advise on governance, project management, procurement and sourcing issues. But all related to IT. The way I do this is like a coach of sports team. I am part of the team, but I don't play the game. If the team wins, I am a hero, if they mess up, I am the one to blame. Very interesting work!
Therefor I created a new "function" late last year: IT architecture Coach. How long will I be like that? I don't know, but if my work changes, so will the label of my role. Unlike many others who want to be proud about their acquired and sometimes certified (by whom?) title. I meet many people who would love to have "... architect" on their card. And some actually do put it on their card, without even knowing what is expected from them....
I guess the debate about functions, roles, titles in IT is not going to end in the near future. The IT industry itself has no benefit in this as confusion results in uneducated clients who are then easier being mislead about their spending. Like Bob: an attack on the very temple of IT.
Written by
This e-mail address is being protected from spam bots, you need JavaScript enabled to view it
on 29-05-2008 03:13
Dear Peter,
It is good to know out thoughts are in line. Outside input from Danny and from you nobody has jumped in yet, so it may be the three of us. Well experience does things to you, and I have seen a large number of companies. The wording is very important in our profession. Information and communication at work.
Yes, I think I know what you are talking about with respect to IT-industry. My main problem there is it does not seem to matter what is done, it just will go on. That is why one of my big issues at the moment is the strength of the organisations who are in need of their information and communication. This fits in what I see in management. IT-management taking the title CIO, while their mind and work is really that of a Technology Officer, usually an IT-officer. As Clinton and Gore made their law in 1996. The problem is that organisations are not really waiting on having IT. IT is like buildings, plants, cars, tools etc. They are all means, part of the third corporate resource. We talked about PIOFAH and COPAFIJTH. All of these are managed as means at tactical level, and with good reason. IT is very expensive for organisation at the moment, so it becomes a major cost for the organisation. But is that a reason to talk about IT-infrastructure at strategic level? Not really, and that is why the current CIO is so often seen as one of the most difficult positions to be. The real strategic issue is information, not IT. The strategic question is what you need to know and how you need to be able to communicate this knowledge to be able to be in business. The current tools, IT and others, currently stand in the way of being able to do what is necessary, and for that reason for a threat to the existence of the organisation. Once this problem is in hand IT will be where it should have been: at tactical level. With a hard conclusion. The current CIO is usually an CITO. The CIO-function needed at Boardlevel is usually not filled at the moment. It is to be someone who knows about the information of the organisation, and his/her knowledge of information as a 4th corporate resource will make her/him strong at demandside. Strong in knowing what (s)he needs when buying and maintaining IT, for instance. The IT-industry tries to claim control over strategic level because their work costs a lot and, at the moment, improvement is needed so bad that what they are saying cannot be ignored. But the reluctance is so obvious. And what you call bad examples are in fact normal. But suppose the IT-solutions they provide would be perfect; how long would they stay in business? I have seen hundreds of organisations and most of them can really size down their IT to less then half, and they would have a much better infrastructure. But spending half will also mean someone is receiving only half…. Another real problem in IT at the moment are the preferred supplier list. A small group of organisations, usually about the same list for many organisations, supply all products and services, demand and supply. This is a humongous mistake. Most important: you will have to have a separation of functions (see the discussion blog of Lydia Duijvestijn of April 5th). With the addition for “customers”: do not hire the IT-industry at your demandside.
Don’t misunderstand: I have much respect for the work of an IT-architect and an IT-Enterprise Architect as long as they keep to their profession as I keep to mine. My experience: if everybody keeps to his or her profession working together will easily result in synergy.
In the last decade I have probably seen in IT-industry a lot more then a 100 titles with the title architect in it. In practice I can see 3 kinds of architect who have a clear and pretty distinct profession and added value. That is why we started to explore certification in 2001, and we have the experience that it works perfectly. Until commerce caught up with it, and saw it as a good way to earn large amounts of money. Competition started nearly from the start, and today the title architect and the certification in the marketplace is not worth the paper it is written on. So if your customer asks for an IT-architect, please look carefully to what they are really asking for. It’s the same as when you see an ad for an business analyst with a thorough knowledge of COBOL. Or the senior principal enterprise architect with a maximum hourly rate of €.80,-, the magic number for the freelance IT-professional. The IT-industry has made a mess of the jobs and the titles they gave these jobs. Their customers are fully lost, and rightly so. But this chaos creates opportunities, and money.
To get to real service definitions of the architect we have to go back to the basis. This basis is in fact really simple. But as long as such an action must come out of the IT-industry it will not happen. And everything is based on the IT-industry at the moment, with very dissatisfied customers. Times they are a changin’.
Well, let’s see. You say “I advise on governance, project management, procurement and sourcing issues. But all related to IT”. In my experience you are not at demand side because you are not looking at corporate resources, but at means. In your case IT. So, what I understand is that you have a broad way to look at your expertise. You’re not specialised in some area like .net, SAP or J2EE. That would indicate the title architect. To determine whether you are an IT-enterprise or an IT-architect you basic competence needs to be determined. Is your thinking based on the way IT is able to create a fitting IT-infrastructure, or are you discussing IT-solutions and IT-landscapes to support an organisation? The first one would be an IT-architect, the second the (IT-)enterprise architect. …You advise on governance. I would expect this governance to be the governance of IT-project and/or System Management. So: IT-governance. …You advise on project management, where projects are most probably IT-projects …You advise on procurement, where procurement is the procurement of IT. From the way you write I expect you advise on the IT-solutions to be procured, and the way these solutions fit into the IT-infrastructure. …You advise on sourcing. Can I assume this sourcing is of IT-professionals. Well, all of these fit perfectly with the IT-architect, or, in case, with the (IT-)enterprise architect.
Being an IT-architect does not mean one will have nothing to do with demandside! The fact is that what happens at demandside is not core to what an IT-architect or (IT-)enterprise architect is and does. Their core is resp. the IT-infrastructure and the application/data landscape. Which means these guys think from their own core competence. Which means their view is different from people having another core competence. As simple as that. With the addition: everyone of the 3 architects are, if they are really competent, of very high value to an organisation. As long as they stay in their field of expertise. If an IT-architect pretends to know all about information (s)he has a lot of surprises coming. And the other way around. This is seen everywhere in practice, I have to say. Don’t ask a painter to solve a real plumbing problem, as simple as that.
I really do not know how to label your work, because you are an individual with your own knowledge, experience and being. In my experience: don’t be afraid to be really good at your profession; it is the best to present yourself, and to show what you are really worth. The rest will follow. And your comparison to the coach of a sports team is a very good one.
Well, IT-architecture coach is a bit of a contradiction in terms. One coaches people, not tools like IT. But if you mean an IT-architect coach, that is a great job to be done by a real senior. Look at the Guilds of the middle ages: that was the way juniors learned their trade. As an external coach you can inject knowledge and experience into an organisation by teaching the people, and that is a great job to do. I know, because coaching is one of my three kinds of jobs too, only on information, not on IT. I’m afraid it is not really a new function, but in fact a very old one. In fact it is standing behind someone, and making him or her stronger in her/his job without doing the job yourselve.
We are working on defining the real roles. I have tried to do that for 20 or 25 years now, and so far without much to show for it. Maybe the time is ripe, today, to do it. It’s not very complicated in itself, it’s complicated to get the IT-vendors in line. This will mean a small set of real titles that can be certified. Not for TOGAF, DYA, Zachman or yet another method, but really based on the profession itself.
It is expected that we have 30.000 IT-people who call themselves architect in the Netherlands alone (IT-population between 140K and 250K). Crazy! Independent certification is pushed in a corner by masses of people and organisations who earn big money by their certification. That is why independent certification has kept a low profile in the last years. It will come back when the market swings back from supplydriven to demandriven. If only IT-users will become mad enough to take back what is theirs, and demand real solutions to their problems. None of the current hypes are real solutions: not SOA, not outsourcing, not IT-governance, not .NET, not SAP, not whatever else.
Well, at the moment there are signs that changes in the IT-business are to happen in a overseeable amount of time. Let’s hope so. So don’t despair. You yourself are one of those signals if you interpret what you are saying in those terms. And it has to start somewhere.
Via Nova Architectura is not responsible for the content of blogs, but authors and readers are asked to adhere the following guidelines. Authors are strongly encouraged to check facts, cite sources, present
balanced views, acknowledge and correct errors. Respect copyright, fair use and financial disclosure laws. Please do not disparage organizations, or individuals. Being critical of someone's practice is acceptable, when it is done in a professional manner. Prevent usage of marketing statements. Comments should be relevant to the specific post they are attached to. Spam, flaming, personal attacks, and off-topic comments are not
permitted. Readers are requested to notify
This e-mail address is being protected from spam bots, you need JavaScript enabled to view it
of any violations. The editor holds the right to remove any statements that, in the editors opinion, infringe the above guideline(s). The author receives a notification of this action.
Given my definition of enterprise architecture, you probably wonder what other forms of architecture do not fall under the definition. One important form of architecture is reference architecture. This form of architecture provide architecture principles and models that are not specific to the organisation. Examples are industry specific architectures such as the IBM Insurance Application Architecture, or technical reference architectures such as the Microsoft Application Architecture for .NET. Ideally you just buy them off-the-shelf or select them from the public domain. In practice, reference architectures are not widespread, well-known or readily applicable (with a few good exceptions). This forces organisations to define their own reference architectures, based on what can be found in the market. What is needed is an adult market of reference architectures, that prevents us from inventing the wheel ourselves everytime over again. I see too many enterprise architectures that are mostly reference architectures; they contain a lot of generally applicable information.
