Hello
This blog has now been moved
thanks - it's been fun!
Monday, August 11, 2008
Monday, March 03, 2008
Why are we here in the first place?
Part 1 of 5 part article…
The primary purpose of an Enterprise Architecture (EA) is to inform, guide, and constrain the decisions for the enterprise, especially those related to IT investments.
The true challenge of enterprise engineering is to maintain the architecture as a primary authoritative resource for enterprise IT planning. This goal is not met via enforced policy, but by the value and utility of the information provided by the EA.
In general, the essential reasons for developing an EA include:
• Alignment—ensuring the reality of the implemented enterprise is aligned with management’s intent
• Integration—realizing that the business rules are consistent across the organization, that the data and its use are immutable, interfaces and information flow are standardized, and the connectivity and interoperability are managed across the enterprise
• Change—facilitating and managing change to any aspect of the enterprise
• Time-to-market—reducing systems development, applications generation, modernization time frames, and resource requirements
• Convergence—striving toward a standard IT product portfolio as contained in the Technical Reference Model (TRM).
Selling EA vs. Building Support
The single most difficult task in delivering and developing and Enterprise Architecture program is gaining support from the enterprise itself. This is why I was so passionate about writing this report. There are many bumps and detours along the way, and if we all can avoid and maneuver them, EA will advance as a whole and become more accepted and understand.
There is little reason to start an EA program itself unless it is supported by the business and treated as a business initiative. It will require executive level commitment and persistence. The IT department should not have to continually go to the well in various user organizations to get their support if there is a good plan and strategy in the beginning.
Want to read the rest? Get my Ten Secrets to Selling Enterprise Architecture and download the entire 33 page article.
Happy Architecting!
Tuesday, January 22, 2008
SOA for the Technology Architect
Hello from the eve of yet another EA Conference
Here I sit in Calgary, pondering some thoughts with respect to the topics at hand at tomorrow's EA Directions "Critical Issues InEnterprise
We discussed the role of the technical architect at length, and specifically that which pertained to services in an SOA and the TA's role. Two very distinct areas that I may not have paid enough attention, were consideration for the specific security concerns that are heightened with an SOA. I did not specifically high light this as a non-functional requirement, but likely should have. It is easy to rattle off the usual suspects such as availability, reliability, blah blah blah. But Security doesn't typically fall into this camp. It may be both functional and non-functional, and should likely be included in that checklist that we architects all peruse when thinking through those considerations that most don't.
Another point worth mentioning, is another complex issue surrounding SOA. After creating and designing the architecture for SOA, we need to ensure we've included an architecture that encapsulates the nature of monitoring, metrics, measurement and management of the operational aspects of the SOA-based services platform. I feel so strongly about these subjects, that I will soon release a special report on measuring such important details of the architecture environment, so come back and I'll be sure to share.
With both of these as critical factors in the SOA, it is very hard NOT to include the Technical Architect in both the design of the initial SOA infrastructure, infrastructure and platform, but should highlight the benefits of including such a role within your overlapped EA and SOA teams in order to ensure you have the right minds creating the best solution for your enterprise.
Happy Architecting,
Sharon
Here I sit in Calgary, pondering some thoughts with respect to the topics at hand at tomorrow's EA Directions "Critical Issues In
We discussed the role of the technical architect at length, and specifically that which pertained to services in an SOA and the TA's role. Two very distinct areas that I may not have paid enough attention, were consideration for the specific security concerns that are heightened with an SOA. I did not specifically high light this as a non-functional requirement, but likely should have. It is easy to rattle off the usual suspects such as availability, reliability, blah blah blah. But Security doesn't typically fall into this camp. It may be both functional and non-functional, and should likely be included in that checklist that we architects all peruse when thinking through those considerations that most don't.
Another point worth mentioning, is another complex issue surrounding SOA. After creating and designing the architecture for SOA, we need to ensure we've included an architecture that encapsulates the nature of monitoring, metrics, measurement and management of the operational aspects of the SOA-based services platform. I feel so strongly about these subjects, that I will soon release a special report on measuring such important details of the architecture environment, so come back and I'll be sure to share.
With both of these as critical factors in the SOA, it is very hard NOT to include the Technical Architect in both the design of the initial SOA infrastructure, infrastructure and platform, but should highlight the benefits of including such a role within your overlapped EA and SOA teams in order to ensure you have the right minds creating the best solution for your enterprise.
Happy Architecting,
Sharon
Subscribe to:
Posts (Atom)
