Day Two Take-Aways
Have you ever considered the iPod as an EA Metaphor for the future? Larry DeBoever, Chief Research Officer of Hitachi Consulting has. I believe that what Larry was trying to say is that Enterprise Architecture (EA) is important because enterprise sustaining innovation is occurring at an ever increasing rate, ever more global, having more impact on enterprises and getting to market faster. If an enterprise isn’t flexible enough and isn’t incubating innovation enough, it will become irrelevant. As Enterprise Architects, we need to transform to be effective in the Innovation Economy.
An interesting question posed was “How do you stay informed about innovation?” Larry’s examples proved only too well that many of us are not doing a very good job.
In studying about strategic planning, another speaker asserted that cultural effects tend to drive performance to the norm or mediocrity. It seems to me that working to understand the business’s strategic plans and to create EA strategic plans and models that support the business is a good proactive investment. Without them, it seems that we’re more reactive to issues rather than working to prevent them.
Jane Carbone of Infomajic gave a talk on the ten signs of EA maturity. I found her framework and methodology to follow a more practical approach than others. Her ten signs are:
Jane’s talk was all the more practical for me since I won her book in a drawing.
Gail Verley of the FDIC mentioned that they were able to get business executives engaged with IT by tying part of their compensation to EA. I’ve never heard of that before. The FDIC has a Technical Review Group that supports the CIO. I’m wondering if we should have one too. Gail mentioned that they have a newsletter that communicates architecture to the enterprise. I think we definitely should start one of those.
Day Three Take-Aways
John Zachman of Zachman International is well-known in EA. If you ever have a chance to hear him speak, I highly recommend that you take it.
From John’s talk, I came to appreciate the implications on the business of “mass customization”. We need to be prepared to support this. The business will come asking for it. It already has in some respects. Mass customization will require great amounts of skill in creating reusable components and their integration. All of this will require engineering. EA without engineering or executability is not architecture.
Without EA, how will you deal with change?
· By trial and error?
· By reverse engineering?
· Start over?
Zachman has created an EA framework that is fairly popular and comprehensive, but possibly a bit overwhelming. It is a way of organizing and classifying EA assets or parts of the architecture. Michael Miller talked about how this framework can be made real more so at the project level. For each project, deliver specifications for each row of the framework.
Alternatively, another speaker from Forrester mentioned that the most popular frameworks are those that enterprises develop themselves. The second most popular is Zachman’s and the third is TOGAF. All frameworks are fundamentally similar. There’s low risk of selecting the wrong one.
Projects that are only focused on the time line are not doing architecture. They’re not paying attention to the attributes that EA is interested in: integration; flexibility; adaptability; reusability; and many others.
Day Four Take-Aways
The premise of the keynote address on the fourth day seemed to continue to support the supposed conference theme of adaptability and agility. An argument was made for model-driven architecture (MDA). The argument was more sound this time around. The last time I heard a discussion, MDA wasn’t as mature. I got the impression that MDA was more of a passing fade. I thought that code generation was the primary benefit. Richard Soley of the Object Management Group proposed today that the primary benefit of MDA is the consensus on models, interfaces and interoperability that comes from a documented integrated architecture, since consensus on hardware platforms, operation systems, network protocols, and programming languages is more difficult if possible at all.
Mel Mireles of HBMG, Inc. gave a talk about “EA Challenges in a Small to Medium Company”. He presented a list of fallacies and pitfalls, but my take-away was the three-legged stool of technology, business, and governance. Consider governance as the “glue” of maintaining and adhering to the enterprise architecture. Another interesting take-away is to not let technology drive your enterprise away from your core competencies.
There was no consensus from a panel of speakers on certification of architects. Some speakers thought we need it. Some thought that there’s no way to be able to affectively do it.
Think of an enterprise architect as an orchestra conductor at an opera – getting all the pieces to harmonize and be responsive to what’s going on onstage. An architect sees more of the enterprise than most in the enterprise without the authority to change the deficiencies, thus relying on collaboration skills.
How do you know when you’ve done enough architecture (versus documenting the current state in detail)? When the business says that you’ve given them enough to make decisions.
If you don’t define the business strategy (e.g., the value), how do you deliver to it?
Day Five Take-Aways
Day five was all about understanding and leveraging service oriented architecture. The focus of SOA is in attaining adaptability, agility, and reuse of services – both internal and external.
SOA is usually thought of as contributing to loosely coupled designs. This notion should be accompanied with the notion of design time. SOA designs are tightly coupled at run-time. If a critical service fails, the application will fail. SOA is loosely coupled at design time with respect to changing integrations more readily.
Don’t under estimate the need to conduct proof-of-concepts. These are critical to prove out the application of the technology to the given enterprise.
Most organizations select their SOA technology at the start instead of near the end. How can this be done without knowing the require enterprise’s requirements. It reminds of the Dilbert cartoon about naming the project first.
There's an interesting thread on what is the opposite of a defect. I'm not sure. Both sides of the arguement are interesting.
Working to improve your company's public web presence will likely bring the title of "Information Architect" into your corporate lexicon. My favorite definition of the field is ... the structural design of shared information environments" as well as "the art and science of organizing and labeling Web sites, intranets, online communities and software to support usability and findability." Information architects (IAs in industry parlance) often work closely with software and Web teams but typically focus on navigation schemes and usability rather than pure design or hard-core coding.
Wikipedia has a concise description of the information architect role, but I feel that it relies to much on the building architecture metaphor.
For a great piece on "information architecture", check out ... An Introduction to Information Architecture
Without really looking for them and just keeping my eyes open, I've found a few articles that have helped me to put together my definition of a software architect.
Martin Fowler is a writer and speaker who often makes a lot of sense to me. I've saved his article "Who Needs an Architect?", because in it I identify with the species of architect that I strive to belong to: "Architectus Oryzus".
While Fowler's piece seemed more practical, I found an article by Rich Newcomb titled "Architect of the Enterprise" that contained an interesting list of characteristics of an enterprise architect.
I kept an adequate background piece by Walter Hurst titled "The Critical Role of Application Architecture" because it seemed to cover a lot of ground. It begins with a good start to a list of issues that architecture might be able to address. The piece goes on to describe the role of architecture, approaches for developing an architecture, issues likely to be encountered, and why some companies buy architectures.
I had the next article for some time. It relies heavily on the constructing-a-building analogy. It is by Marc Sewell and is titled "Are You a Software Architect?"
While not specifically focused on architecture, Wayne Eckerson wrote a good column that compares and contrast leaders with managers. I believe that an effective architect needs to also be a leader.
Visit my web page. My blog has moved to
Subscribe to my feed: 
