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
Tuesday, October 02, 2007
Technology Landscape - Your Best Target?
In putting some efforts towards my fall seminar schedule, I have been focused on my technology architecture workshops and had a thought today worth sharing.
As enterprise architects, we attempt to capture business strategy and put some alignment to our IT Strategy, and formulate an IT Current State and IT Target State architecture. The IT plan is the people, process and technology initiatives that we plan for the year, and potentially two or three threes out to move towards IT future State.
We have to have an understanding of the business strategies, priorities and external business environments to drive the overall strategic IT objectives. Analysis of the business changes and priroities drive the characteristics of the IT products and services, IT governance and the required IT capabilities.
IT Architecture is how we plan, and the basis for the efforts that we employ during the year to move closer to our goals. Definition of the technology, application and data architectures enable the IT strategy. Each must align with the business architecture, or functions and processes that we perform as an organization to sell or provide service to our customers. Effective IT planning is derived from tactically focusing on closing the gap between current state and target state.
The technology landscape is where my thoughts lie today. IT strategy is a business driven lifecycle, and it's difficult to jump directly to the technology landscape when reviewing the linkage and relationships from the business. IT planning is an on-going event constantly refreshed to meet the shifting future state. It makes sense after we determine which data we need, and what solutions we will use to provide or manipulate that data. It is only after this point that we can determine which technologies we will use to deliver these solutions.
What if we consider the big jar and the stone philosophy? We have a large jar, and we fill it first with big stones, then smaller stones, then pebbles, sand and water to fill it. Our large stones in the area of technology architecture shouldn't change often. Meaning - if we have an IBM mainframe solution, using a Nortel or Cisco network, and HPUX server farm, we've determined how we general want to continue to operate. Although we may have quite a mixture, we should generally know what our general direction is on the larger technology components each year - or which direction we intend to move as big changes are made.
These technologies will rarely have wholesale changes. Our technology landscape will generally stay the same, yet each year we must consider which larger and smaller scale changes should be made. There are none that should be made purely for sake of change itself, nor for the sake of "cool and new" technologies, unless innovation is our core business product.
In saying this, we as technology architects have the best chance of putting together our target state with the most certainty. Each solution and information requirement will cause us to change direction somewhat. We as technology architects should attempt to map how our technology components match to the business drivers in our strategic plans, but if this isn't possible for us, or resides with our enterprise architects, it behooves us to have a very good understanding of the categories of technology components that we carry, the ones that should be slated for replacement, and those that should be enhanced.
Technology Landscape is most likely the most straight forward target state of the three domains. The minor stuff like lists of specific point software, appliances, etc. can be added as our needs are nailed down.
If technology architecture interests you, watch our seminars page at www.architectbootcamp.com for more information.
As enterprise architects, we attempt to capture business strategy and put some alignment to our IT Strategy, and formulate an IT Current State and IT Target State architecture. The IT plan is the people, process and technology initiatives that we plan for the year, and potentially two or three threes out to move towards IT future State.
We have to have an understanding of the business strategies, priorities and external business environments to drive the overall strategic IT objectives. Analysis of the business changes and priroities drive the characteristics of the IT products and services, IT governance and the required IT capabilities.
IT Architecture is how we plan, and the basis for the efforts that we employ during the year to move closer to our goals. Definition of the technology, application and data architectures enable the IT strategy. Each must align with the business architecture, or functions and processes that we perform as an organization to sell or provide service to our customers. Effective IT planning is derived from tactically focusing on closing the gap between current state and target state.
The technology landscape is where my thoughts lie today. IT strategy is a business driven lifecycle, and it's difficult to jump directly to the technology landscape when reviewing the linkage and relationships from the business. IT planning is an on-going event constantly refreshed to meet the shifting future state. It makes sense after we determine which data we need, and what solutions we will use to provide or manipulate that data. It is only after this point that we can determine which technologies we will use to deliver these solutions.
What if we consider the big jar and the stone philosophy? We have a large jar, and we fill it first with big stones, then smaller stones, then pebbles, sand and water to fill it. Our large stones in the area of technology architecture shouldn't change often. Meaning - if we have an IBM mainframe solution, using a Nortel or Cisco network, and HPUX server farm, we've determined how we general want to continue to operate. Although we may have quite a mixture, we should generally know what our general direction is on the larger technology components each year - or which direction we intend to move as big changes are made.
These technologies will rarely have wholesale changes. Our technology landscape will generally stay the same, yet each year we must consider which larger and smaller scale changes should be made. There are none that should be made purely for sake of change itself, nor for the sake of "cool and new" technologies, unless innovation is our core business product.
In saying this, we as technology architects have the best chance of putting together our target state with the most certainty. Each solution and information requirement will cause us to change direction somewhat. We as technology architects should attempt to map how our technology components match to the business drivers in our strategic plans, but if this isn't possible for us, or resides with our enterprise architects, it behooves us to have a very good understanding of the categories of technology components that we carry, the ones that should be slated for replacement, and those that should be enhanced.
Technology Landscape is most likely the most straight forward target state of the three domains. The minor stuff like lists of specific point software, appliances, etc. can be added as our needs are nailed down.
If technology architecture interests you, watch our seminars page at www.architectbootcamp.com for more information.
Monday, October 01, 2007
Setting Your Scopes
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.
I responded within the parameters of Enterprise Architecture at a company. EA provides IT governance and stewardship for any future technology planning and roadmap within a company or organization. An architect considers fundamental business drivers, structure of a system, it's components and relationships and then creates or tunes the best design to meet the needs of the business drivers and the organizational goals.
In most organizations, there are many systems that may cross boundaries, and many people in various roles with varying responsibilities that blur these lines. Evolution of one system to achieve a goal is often not achievable without understanding the relationship to other systems. This is the scope of Enterprise Architecture and the EA - he or she must know about the scope of all the systems and make the best decisions possible for the greater good of the organization.
The scope includes knowing how systems and their components interact, and their relationships to other systems and their components. Scope of EA includes the principles that govern the design and evolving life of all of the systems. The skill of the enterprise architect is in their abilities to see things conceptually, and be able to scale up or down, seeing bottom-up and top-down whenever they desire to take another view, and to keep this is mind when making key and fundamental decisions.
They require the understanding of it's relationship to all of the systems, needs, goals and desires of the organization. Making decisions without understanding this relationship is like designing a community in the desert without considering how air, rail and vehicle travel will reach it - the distance to the nearest power, water and electrical resources, and position on earth's topography for all such needs. Regard for infrastructure is critical, and the style of the community based on earth's disasters is the responsibility of such a planner.
These kinds of responsibilities like with the Enterprise Architect, so understanding the fit of the system to the organization is like the analogy of a town to earth's landscape and the planners who must create great places to live. The EA is also responsible for ensuring that growth of the town can happen naturally, without crisis and that effective living can occur when introducing new services that those who dwell here need them.
I responded within the parameters of Enterprise Architecture at a company. EA provides IT governance and stewardship for any future technology planning and roadmap within a company or organization. An architect considers fundamental business drivers, structure of a system, it's components and relationships and then creates or tunes the best design to meet the needs of the business drivers and the organizational goals.
In most organizations, there are many systems that may cross boundaries, and many people in various roles with varying responsibilities that blur these lines. Evolution of one system to achieve a goal is often not achievable without understanding the relationship to other systems. This is the scope of Enterprise Architecture and the EA - he or she must know about the scope of all the systems and make the best decisions possible for the greater good of the organization.
The scope includes knowing how systems and their components interact, and their relationships to other systems and their components. Scope of EA includes the principles that govern the design and evolving life of all of the systems. The skill of the enterprise architect is in their abilities to see things conceptually, and be able to scale up or down, seeing bottom-up and top-down whenever they desire to take another view, and to keep this is mind when making key and fundamental decisions.
They require the understanding of it's relationship to all of the systems, needs, goals and desires of the organization. Making decisions without understanding this relationship is like designing a community in the desert without considering how air, rail and vehicle travel will reach it - the distance to the nearest power, water and electrical resources, and position on earth's topography for all such needs. Regard for infrastructure is critical, and the style of the community based on earth's disasters is the responsibility of such a planner.
These kinds of responsibilities like with the Enterprise Architect, so understanding the fit of the system to the organization is like the analogy of a town to earth's landscape and the planners who must create great places to live. The EA is also responsible for ensuring that growth of the town can happen naturally, without crisis and that effective living can occur when introducing new services that those who dwell here need them.
Thursday, September 27, 2007
What is the same, and what has changed?
Someone asked me a philosophical, yet, appropriate question the other day.
Why do I still continue to use a very simple framework in my coaching and consulting with Enterprise Architecture? I began using something called BAIT (business, application, information and technology), and turned to something else - BOAIT (business, organization, application, information and technology).
I thought for quite a while, and went through what has changed since I started working in the Enterprise Architecture space.
We went from application architecture, through system architecture (which now might be known as technical architecture). I saw Meta put forward a combined application and data layer called solution, and now we've hit the peak in the area of solution architecture (whereas no one really speaks of application architecture anymore).
Do we use Zachman, Dodaf, FEAF, or something else? It's all a matter of classification, and the purpose is communication. The clearest method has to be sufficient. The rest is background noise - it's about doing and using architecture, not just defining it.
My answer is simple. I started with a very excellent book that was very appropriate in the mid 90's. It is Steven Spewak's Enterprise Architecture book. At the end of the day, it all boils down to Applications (solutions if you may), Data and Technology. The business drives all of the other architectures, as they are wound within the strategic plans. None of that can really change - we can add SOA, Security Architecture, or change how we term what goes on in the operations and technical areas and we will still boil it down to all of this.
Our business strategy drives which data we need to collect, process and transmit. The systems/applications and solutions will provide mechanisms to make these transformations, and the technology in the areas of software, hardware, configuration, etc. will physically allow it to be so.
Nothing has really changed my perspective - just some of the details around how and why I would collect, analyze and interpret what I've categorized.
Why do I still continue to use a very simple framework in my coaching and consulting with Enterprise Architecture? I began using something called BAIT (business, application, information and technology), and turned to something else - BOAIT (business, organization, application, information and technology).
I thought for quite a while, and went through what has changed since I started working in the Enterprise Architecture space.
We went from application architecture, through system architecture (which now might be known as technical architecture). I saw Meta put forward a combined application and data layer called solution, and now we've hit the peak in the area of solution architecture (whereas no one really speaks of application architecture anymore).
Do we use Zachman, Dodaf, FEAF, or something else? It's all a matter of classification, and the purpose is communication. The clearest method has to be sufficient. The rest is background noise - it's about doing and using architecture, not just defining it.
My answer is simple. I started with a very excellent book that was very appropriate in the mid 90's. It is Steven Spewak's Enterprise Architecture book. At the end of the day, it all boils down to Applications (solutions if you may), Data and Technology. The business drives all of the other architectures, as they are wound within the strategic plans. None of that can really change - we can add SOA, Security Architecture, or change how we term what goes on in the operations and technical areas and we will still boil it down to all of this.
Our business strategy drives which data we need to collect, process and transmit. The systems/applications and solutions will provide mechanisms to make these transformations, and the technology in the areas of software, hardware, configuration, etc. will physically allow it to be so.
Nothing has really changed my perspective - just some of the details around how and why I would collect, analyze and interpret what I've categorized.
Tuesday, August 28, 2007
Architecture or System Requirement - What's the Difference?
Lately, I've been working on the Architect Boot Camp info site and trying to lay out some really basic architecture information and some more advanced stuff. It dawned on me that there might be some who don't understand the difference between system requirements and architectural requirements. If this is news to you - stick with me. If not, I won't waste your time - catch you later.
Architecture requirements are typically those you collect during the initial scoping and context setting sessions at the beginning of a project while you are collecting high level system requirements. You need to determine the business objectives for the system, and for the architecture specifically.
It is so important to ensure that the architecture is aligned with the business drivers and objectives for the project. The architect keeps his or her eye on knowing where VALUE WILL BE ACHIEVED. What are the stakeholder goals? Main criteria for success?.
Setting system context helps to measure scope and set the appropriate boundaries. The architect needs to understand what the system interface will be, and what factors will characterize the architecture. Getting a list of top-level and high-priority goals will assist in setting this scope. This list can be further expanded when moving towards the elaboration phase of the project, and further gather the functional requirements.
The infrastructure must be designed to support the services and functionality that users require. It must deliver the appropriate levels of performance, security, usability and flexibility. All are factors that must be considered at the very beginning during the structure design and concept building of the solution architecture.
If the product is being purchased, the solution or system architects must review the requirements in order to determine their relevance and completeness. Specifically - those relating to non-functional requirements - specifically in the areas of performance, volume, methods of doing transactions or using the system, whom will use the system, how they will use it, etc. require review by the architects.
The architect must also ensure that these architectural requirements align with the Enterprise Architecture view. There are standards that are set for an organization, and typical infrastructures and patterns that are acceptable. Knowing, studying, analyzing these considerations in advance make up the architecture requirement gathering efforts for the early stages of the project.
These requirements need to be included in the solution architecture documentation set, and potentially used for volume, stress, and usuability testing during prototyping stages if the technologies are new, or if the requirements are risky.
Pure business functionality are user and system requirements. These are typically gathered by the systems and business analysts. An overview of such requirements should be held with the architect to ensure that they don't become intermingled, but there are shades of grey when it comes to "which documentation set" they belong to. You are a smart individual - you'll figure it out.
For more on architecture how-to's, visit The Architect Boot Camp.
Happy Architecting!
Subscribe to:
Posts (Atom)
