In a previous article, the spotlight fell on three biggest risks the Chief Architect needs to manage before moving onto something less tactical. Consider now the area of strategic planning and opportunities in your future state landscape. Three key sources that the chief architect needs to explore are:
It’s been far too long but I’m writing again – you see I’ve been writing a lot since I last wrote and so there are lots of pieces that should be appearing here soon – I’ll just have to figure out where to start. I’ve been doing a lot Read the rest…
Enterprise Architecture – Benefits
- Environmental Factors
- Large applications are complex and incorporate other applications & components.
- Need for standard interfaces and products
- We continually need to accommodate change, and a review of our infrastructure each time we need to make a change is cost and time prohibitive
- System design modifications & upgrades now are needed on weekly or monthly schedules
- We are finally building applications that we expect to change, and need to have a solid, well thought out foundation on which to build them
Expected Benefits
- Improved alignment of IT solutions with business strategy
- Greater ability to set realistic IT goals
- Enhanced enterprise information sharing
- Reduced software and data redundancy
- Reduced information systems complexity
- Greater reliability at implementations & updates
- Reduced dependency on key resources
- Improved accuracy in scheduling software development / implementation
- More accurate forecasting of development and support costs
- More efficient deployment of technology solutions
- Increased traceability
Tangible Benefits
- Promote better planning and decision making
- Improve communication through standardized vocabulary
- Views communicate complexity and facilitate management
- Enable strategic use of emerging technologies
It’s nearing end of summer and slowly, folks are getting back from vacation or they are out shopping for school supplies. Maybe a last minute golf game with friends, or perhaps colleagues. A day at the beach if weather permits. As we see the first signs of the leaves turn Read the rest…
Monday is as good as any to do something new. For most, above average. Well – today I figured I’d **make** the time to move this blog to the Architect Boot Camp site. Here it is – hope you benefit from it and I do have plans (hopes) to post Read the rest…
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.
** Note – As of Jan 1 2009, this report is no longer available publicly. If you want the details, go to our Membership Portal ** Read the rest…
Recently, one of the people I have been coaching in the area of Enterprise Architecture asked me a great question – one worth posting here. He said “what is the scope of the Enterprise Architect?” in context to the head of Application Development, the Lead Analyst or the Solution Architect. Read the rest…
Happy New Year! It’s nice to be back again and writing about my favorite topic. This spring I’m speaking at the Enterprise Architectures Conference on Quick Wins in Enterprise Architecture so I thought I’d share a bit of the content. Enterprise Architecture as a new program within a Read the rest…
Does it ever seem that as an Enterprise Architect, we have many dragons to slay? Our organizations confuse the Chief Architect with chief technology problem solver, and it isn’t their fault. Often the current technology hot spot of the day is something that lives in the EA realm, and we are the captain of the ship. We’ve had many metaphors – the Builder, the Architect of a house, the City Planner, or perhaps the Pilot of an airplane or ship (thanks Mr. Zachman!). Here is mine: An organization, when embarking on an EA program, needs a cook. They need to mix some things up to create a tantalizing dish. There is not often one recipe, but several that might suit the ingredients you have at hand. At some point, depending on the size of the organization, you may find that there are too many cooks in the kitchen, and a chef de maison, or Head Chef is required. The chef will prepare the menu, and ensure that the restaurant has the ingredients at hand. What the cooks do to add flavor and seasoning may be their choice, or it may be strictly regulated. The McDonalds restaurant does much to ensure that their food tastes the same each and every time. Some restaurants to do – these are not chains, but individual “spots” for a bite out. Sometimes, there are too many cooks in the kitchen. As of late, I’ve seen several folks try their hand at mixing and matching SDLC’s. The chief architect may or not get involved from a standards perspective, or from a governance and compliance issue with respect to artifacts. There is no “right” SDLC. The facts are simple – too many cooks will ruin the soup – too many flavors will confuse the issue. One recipe may be selected for the best “dish of the house”. There is room to decide whether the head chef is creating the meal depending on the appetite. If there is appetite for chateau briande, so be it. The SDLC will be complex with many options. If there is only appetite for deli or fast food, or perhaps even the corner restaurant that sells burgers and fries, the SDLC must be simple with few key artifacts and simple methods. Chefs – the choice is yours. Remember, if there are too many cooks in the kitchen, there will be a fire! Happy Architecting.
Ok – so maybe you haven’t heard the buzz about the marriage between EA and Portfolio Management. It’s been going on long enough to get the seven year itch already – so why should I go on about that today? My head hurts – I’ve been knee deep Read the rest…