Something I have struggled with in my first years of being an enterprise architect was how to align with the business analysts in our organization. I found it a lot easier to have a 30 minute meeting with the client to understand their needs than reading the entire business requirements document.
It was not until I became a business analyst myself that I realized by the time the enterprise architect gets involved in the project, the business analyst have prepared the business so that they can give you the understanding in 30 minutes. It takes weeks, if not months, of workshops with clients to get them to understand what they really need and to condense it down to a few pages of requirements. The time spent with clients during the business analysis phase of a project is never wasted time, as I always thought.
Enterprise architects should leverage, and appreciate, the business analysts in the organization. They have a specific skill in dealing with clients that most architects lack and does come in very handy during solution selection and detail design workshops. While the architect is busy positioning the solution with the architecture, the business analyst can assist with impact assessments, modelling and client relationship management.
Aligning yourself with a good business analyst makes an architect's life a lot easier.
Showing posts with label EA. Show all posts
Showing posts with label EA. Show all posts
Tuesday, January 29, 2013
Understanding Meta-models
I have always found it strange that at every architecture
conference and meeting I have attended there was always a discussion around
which meta-model to use, which one is the best, and comparing how fully
populated everyone’s is. To me it is not about the meta-model, but rather the
understanding, and business benefits that it brings.
An architect is someone that is supposed to understand the
business, not parts of the business, but the business as a whole. An architect
is supposed to see the relationships between processes and systems (Not just IT
systems). In order to obtain this understanding, you must know what is
important to know, and even more important, what is important to document. This
in my mind is the purpose of a meta-model.
In 2006, we realized that we need an improved meta-model. We
hired in some consultants to assist us to develop the meta-model. Due to the nature
and time of the project only a few architects could afford their time to
develop the meta-model. This lead to gaps and miss-alignment in the meta-model.
We had a great picture to put on the wall but no one understood what the
purpose of all the information was. Adopting a meta- model, even through a consultative
process, leads to a loss of understanding and it is critical that architects understand
the why more than the what.
The construction and completeness of the meta-model is
determined by the questions that your business will need answers to. If your
business is in the retail industry where profit margins are constrained, then
you might focus more on processes and process integration than documenting
detailed server specifications. On the other hand, if you are in the IT
services sector, focusing on cloud computing, then the inverse might be more
important. In all situations a meta-model should reflect the priorities of the
business.
My recommendation to any architect starting at a company, or
an architecture team building a meta-model is to obtain the understanding of
the business first before attempting to create a meta-model. You will in any case
start documenting the business through projects that you are involved in and in
this process discover what information you need to capture and to what level of
detail.
The value of a meta-model lies not in the information, but
your ability to understand and put it in context to answer business questions.
Sunday, November 4, 2012
Architecture Implementation
Implementing an architecture is often a very challenging process in companies. Architects know what is the right thing to do, but how to get it implemented is the challenge. The difficulty is convincing business to buy into an idea that will deliver value in the future. Building a business case that shows direct benefits is difficult enough, and convincing finance on risk alone without a user screaming for it is all but impossible.
Architects has to get their hand dirty in order to implement an architecture. The only way is to do projects, lots of projects. The point is to identify the right project, with a strong enough business case and sponsor support, to implement the architecture the business needs.
No business, unless they have very strategically focused CEO, is going to implement a business intelligence system that cost millions to do reporting, just because you say so. It requires a big enough project, with significant user requirements, and a strong business case.
In order to implement the architecture, architects first have to design, and agree, on what is the priority for implementation. The priority is based on several factors: strategic alignment, business impact, cost and architecture dependencies.
In short: design the architecture, prioritise the implementation and select the most appropriate project/s for implementation.
Architects has to get their hand dirty in order to implement an architecture. The only way is to do projects, lots of projects. The point is to identify the right project, with a strong enough business case and sponsor support, to implement the architecture the business needs.
No business, unless they have very strategically focused CEO, is going to implement a business intelligence system that cost millions to do reporting, just because you say so. It requires a big enough project, with significant user requirements, and a strong business case.
In order to implement the architecture, architects first have to design, and agree, on what is the priority for implementation. The priority is based on several factors: strategic alignment, business impact, cost and architecture dependencies.
In short: design the architecture, prioritise the implementation and select the most appropriate project/s for implementation.
Tuesday, November 25, 2008
The Value of Enterprise Architecture
The most asked question through my various interactions with Enterprise Architects around the world is: “What does Enterprise Architects do?”. Explaining to general business people that architects develop the blueprints of the business seems only to confuse them more. The discussion usually ends up in a discussion of the toolsets. The tools used by architects are used to promote reuse and standardization.
The architecture toolset consists of methodologies (processes) and tools (documents and applications). Methodologies consist of strategy analysis and solution development processes, and tools are generally the meta-model, principles and standards.
Strategy analysis in most businesses today follows an unstructured approach, and process and solution development may have some structure, but generally is done in silos throughout the enterprise. One of the most valuable contributions of Enterprise Architecture is taking what was previously mostly guesswork and transform it into a science. Through the methodology and tools of enterprise architecture both the strategy analysis process and solution development processes are structured, delivering traceable and trackable solutions.
Strategy analysis is the architecture world does result in the same output as any other strategy development methodology, however the process which is followed deliver improved accuracy and traceability. META, which is now part of Gartner, developed the Enterprise Architecture Strategy process. This process analyzes strategy by breaking each element on the strategy into business drivers, information requirements, architecture requirements, and solutions. Each of the steps results in a traceable strategy breakdown into solutions, ensuring alignment between IT and the enterprise.
Enterprise Architecture also brings structure to the solution development process through following the architecture meta-model. A common solution development framework is achieved throughout the different business units through the meta-model. It specifies the artifacts that needs to be captured and how they relate to each other, as well as the levels and structures of the artifacts. The standardization of the development of solutions also assists the architects in their efforts to standardize, optimize and improve reuse of the overall architecture.
The meta-model focuses on what must be documented in the enterprise blueprint, following the good-enough principle. The first decision for the meta-model is what domains will be needed in terms of the architecture. These domains can follow any of the established architecture frameworks currently available in the market (Zagman, DODAF, TOGAF, TEAF, FEAF, etc.). These frameworks provide a valuable starting point for the development of the meta model, however the decision of what is critical to capture, and in what detail is independent of the framework. A study conducted by Jaap Schekkerman in 2003 showed that most companies still use internally developed frameworks, with Zagman a distant second.
Enterprise Architecture is still an evolving field and will only reach maturity in another 5-10 years, when compared to other engineering disciplines. Yet Enterprise Architecture already has a lot to offer to the business through involvement in the strategy and solution development processes.
The architecture toolset consists of methodologies (processes) and tools (documents and applications). Methodologies consist of strategy analysis and solution development processes, and tools are generally the meta-model, principles and standards.
Strategy analysis in most businesses today follows an unstructured approach, and process and solution development may have some structure, but generally is done in silos throughout the enterprise. One of the most valuable contributions of Enterprise Architecture is taking what was previously mostly guesswork and transform it into a science. Through the methodology and tools of enterprise architecture both the strategy analysis process and solution development processes are structured, delivering traceable and trackable solutions.
Strategy analysis is the architecture world does result in the same output as any other strategy development methodology, however the process which is followed deliver improved accuracy and traceability. META, which is now part of Gartner, developed the Enterprise Architecture Strategy process. This process analyzes strategy by breaking each element on the strategy into business drivers, information requirements, architecture requirements, and solutions. Each of the steps results in a traceable strategy breakdown into solutions, ensuring alignment between IT and the enterprise.
Enterprise Architecture also brings structure to the solution development process through following the architecture meta-model. A common solution development framework is achieved throughout the different business units through the meta-model. It specifies the artifacts that needs to be captured and how they relate to each other, as well as the levels and structures of the artifacts. The standardization of the development of solutions also assists the architects in their efforts to standardize, optimize and improve reuse of the overall architecture.
The meta-model focuses on what must be documented in the enterprise blueprint, following the good-enough principle. The first decision for the meta-model is what domains will be needed in terms of the architecture. These domains can follow any of the established architecture frameworks currently available in the market (Zagman, DODAF, TOGAF, TEAF, FEAF, etc.). These frameworks provide a valuable starting point for the development of the meta model, however the decision of what is critical to capture, and in what detail is independent of the framework. A study conducted by Jaap Schekkerman in 2003 showed that most companies still use internally developed frameworks, with Zagman a distant second.
Enterprise Architecture is still an evolving field and will only reach maturity in another 5-10 years, when compared to other engineering disciplines. Yet Enterprise Architecture already has a lot to offer to the business through involvement in the strategy and solution development processes.
Wednesday, September 10, 2008
Enterprise Architecture as the architecture of the enterprise
What is Enterprise Architecture? Is it the collection of the business processes, information, applications and technology captured in the meta-model? Is it the list of best practises and standards that the IT organization uses? Is it the strategy analysis and resulting list of activities that the IT organization needs to execute to enable business strategy?
What I have just described is a few elements that the industry deems EA should do, therefore this is what EA is, isn't it? I believe EA is more, much more that this. In fact I believe EA needs to evolve beyond being Enterprise Architecture for IT to becoming Enterprise Architecture for the Enterprise.
This is unfortunately how most Enterprise Architecture groups are positioned. They were established by the CIO in the IT department, where the core members of the team have previously been either senior developers or system designers. The application of the methodologies of EA is limited to the IT organization, with most of the business improvements occurring on the fringes where IT and the business meet: process automation.
EA for IT is not necessarily incorrect or “bad”. It merely reflects the current sate of understanding of architecture. It adds significant business value to the organization, but from my perspective the true power of EA is the different focus and methods it can bring to the business as a whole. With IT becoming so entrenched into business’s daily operations, a business function with an IT flavour in required, as is a business function with financial, human resources, procurement, etc. experience required. All these business functions plays a part in the organization as a whole. All of these functions have a say in the strategy of the business.
According to The Open Group, Enterprise Architecture is the architecture of the enterprise. The keyword is enterprise, not the different business units, functional departments, or systems running in the organization. The focus is on how the enterprise functions, its operating model, and how to enable this.
When you look at a mining company, there may be various business units that each specializes in their own areas, e.g. the coal mining division, the platinum mining division, various processing divisions, etc. Similarly a financial company, e.g. a bank, has a credit card division, cheque division, home loans, etc. Yet, when you are an enterprise architect, the business units or divisions are not your primary concern or focus. The different divisions may be divided into the way the enterprise operates, but the focus should be one level higher, on how the enterprise functions.
Taking the mining example for instance; the enterprise focus is mine, process, sell. In the banking example could be obtain funds, manage funds, provide funds. This is the highest level of processes in the enterprise, or macro level. It reflects the enterprise, and not the business units or divisions within it necessarily.
In focussing on the enterprise, EA becomes another element in the functioning of the organization. It deals with the strategy, key programs and decisions, and impacts of business decisions within the organization as a whole. It provides another view on the organization from an IT perspective similarly to the financial function providing a financial view and the HR function providing an HR view. Forming an integral part of the organization, EA becomes more than just an enabler to the business; EA becomes a driving force within the business.
What I have just described is a few elements that the industry deems EA should do, therefore this is what EA is, isn't it? I believe EA is more, much more that this. In fact I believe EA needs to evolve beyond being Enterprise Architecture for IT to becoming Enterprise Architecture for the Enterprise.
This is unfortunately how most Enterprise Architecture groups are positioned. They were established by the CIO in the IT department, where the core members of the team have previously been either senior developers or system designers. The application of the methodologies of EA is limited to the IT organization, with most of the business improvements occurring on the fringes where IT and the business meet: process automation.
EA for IT is not necessarily incorrect or “bad”. It merely reflects the current sate of understanding of architecture. It adds significant business value to the organization, but from my perspective the true power of EA is the different focus and methods it can bring to the business as a whole. With IT becoming so entrenched into business’s daily operations, a business function with an IT flavour in required, as is a business function with financial, human resources, procurement, etc. experience required. All these business functions plays a part in the organization as a whole. All of these functions have a say in the strategy of the business.
According to The Open Group, Enterprise Architecture is the architecture of the enterprise. The keyword is enterprise, not the different business units, functional departments, or systems running in the organization. The focus is on how the enterprise functions, its operating model, and how to enable this.
When you look at a mining company, there may be various business units that each specializes in their own areas, e.g. the coal mining division, the platinum mining division, various processing divisions, etc. Similarly a financial company, e.g. a bank, has a credit card division, cheque division, home loans, etc. Yet, when you are an enterprise architect, the business units or divisions are not your primary concern or focus. The different divisions may be divided into the way the enterprise operates, but the focus should be one level higher, on how the enterprise functions.
Taking the mining example for instance; the enterprise focus is mine, process, sell. In the banking example could be obtain funds, manage funds, provide funds. This is the highest level of processes in the enterprise, or macro level. It reflects the enterprise, and not the business units or divisions within it necessarily.
In focussing on the enterprise, EA becomes another element in the functioning of the organization. It deals with the strategy, key programs and decisions, and impacts of business decisions within the organization as a whole. It provides another view on the organization from an IT perspective similarly to the financial function providing a financial view and the HR function providing an HR view. Forming an integral part of the organization, EA becomes more than just an enabler to the business; EA becomes a driving force within the business.
Subscribe to:
Posts (Atom)
Posts
