Enterprise architects are the one star generals of their business. They have some authority. Usually less than their subordinates believe they have, and more than their superiors and peers want them to have. Ultimately, it comes down to the individual architects vision and their ability to lead others to accomplish the tasks needed to achieve it.
Vision is a key differentiator. Specifically, those architects with clarity of scope and definition thrive and succeed where others fail to achieve. Ours is a job centered on communicating complex, frequently abstract, concepts which while providing re-occurring long-term value on what appears to be little more than another wasteful expense in this year’s accounting.
How then are we to justify the expansive nature of our goals?
First, don’t follow the money, lead with it. If your architecture is chasing the “funded” projects seeking to ride their fiscal wave, you are doomed to over-promise and under deliver. As soon as you become a dependency to another project the implied value of an enterprise effort is subverted by the immediate (and very real) needs of the project. Instead you must fight your own fight and develop a funding stream dedicated to enterprise development. Only then can you produce components so valuable to the projects that the projects will be drawn to by the obvious savings or ease of development.
Next, it’s not enough to tell those around you about your goals and their obvious value to the enterprise, you must establish and actively pursue a marketing campaign. Although you will need to advertise both the availability and features of your enterprise architecture, a great deal of the marketing efforts must focus on gathering mind share. Think political campaign. You don’t need sales you need support, trust, credibility, and power. You need to build both a constituency to represent and a majority consensus among those with similar but not necessarily like minded views.
Lastly, Technical users of your enterprise products are swayed by applied technology and cogent discussions of the pluses and minuses associated with a particular choice. Give it to them. Armed with working prototypes, running code, metrics on performance, and well documented APIs you will be allowed to begin the conversation. Don’t for a moment believe you position, title, or self importance will ensure adoption. Know the current application development process … its value and its warts. Chances are software has been built and successfully deployed. Suggestions of change must be complete and compelling.
From http://blogs.msdn.com/stcohen/archive/2004/04/11/111329.aspx
Vision is a key differentiator. Specifically, those architects with clarity of scope and definition thrive and succeed where others fail to achieve. Ours is a job centered on communicating complex, frequently abstract, concepts which while providing re-occurring long-term value on what appears to be little more than another wasteful expense in this year’s accounting.
How then are we to justify the expansive nature of our goals?
First, don’t follow the money, lead with it. If your architecture is chasing the “funded” projects seeking to ride their fiscal wave, you are doomed to over-promise and under deliver. As soon as you become a dependency to another project the implied value of an enterprise effort is subverted by the immediate (and very real) needs of the project. Instead you must fight your own fight and develop a funding stream dedicated to enterprise development. Only then can you produce components so valuable to the projects that the projects will be drawn to by the obvious savings or ease of development.
Next, it’s not enough to tell those around you about your goals and their obvious value to the enterprise, you must establish and actively pursue a marketing campaign. Although you will need to advertise both the availability and features of your enterprise architecture, a great deal of the marketing efforts must focus on gathering mind share. Think political campaign. You don’t need sales you need support, trust, credibility, and power. You need to build both a constituency to represent and a majority consensus among those with similar but not necessarily like minded views.
Lastly, Technical users of your enterprise products are swayed by applied technology and cogent discussions of the pluses and minuses associated with a particular choice. Give it to them. Armed with working prototypes, running code, metrics on performance, and well documented APIs you will be allowed to begin the conversation. Don’t for a moment believe you position, title, or self importance will ensure adoption. Know the current application development process … its value and its warts. Chances are software has been built and successfully deployed. Suggestions of change must be complete and compelling.
From http://blogs.msdn.com/stcohen/archive/2004/04/11/111329.aspx