You have reached this page because you would be most interested in the Business Architect Boot Camp workshop.
- Business Strategy
- Environmental forces
- Business Vision
- Business models
- Business policy
The 5th state that I show on this diagram is to map the technology architecture against the business architecture.This mapping would provide us great value in that if we were to change a business architecture it would allow us to peer inside to the technology that we
In the past, I attended a seminar on Disaster Recovery. It was a little ill-titled, as it should have been called “Impacts to your Business and Organization Architectures by Pandemics”. A bit of a reach, but to me, that was the topic. It was a perspective I had never paid much attention to, as it usually takes awhile for me to join in with the chicken little’s of the world and “the sky is falling” routine.
Disaster Recovery is typically years of planning for a major event where pandemic planning is essentially determining which pieces of your business is non-critical so that you may take it down gracefully because you don’t have enough people to run it. How many of you have business processes that are able to facilitate that question?
Years ago, I was responsible for figuring out which databases were critical to an organization I worked at because the century’s biggest flood was coming. What if we had to relocate and run our business else where? Which systems were the most critical and which databases would we need to make available somewhere else? We were situated at the lowest level in the city, and would likely have to move if our core flood prevention methods failed.
Now turn the tables for a minute – if I had a team of ten database resources working everyday to keep the systems supported, two system resources, a security guard and a building maintenance resource, how many could be affected by a pandemic if one should hit my city? Who would decide what needed to move? Or more likely – what database operation or support function didn’t need to get done for some undefinable future?
Now even more likely, if you have a call list, what are the chances that someone on that list would be affected? How would you contact the others to get replacements if the city or area is engolfed in chaos. As the presentation suggested, many wouldn’t want to leave their homes for fear of being affected by others. Do you have a plan in place by your business architecture as to priorities for keeping your minimum technologies running?
Just a few thoughts that got me thinking about what I might suggest to a few of my customers that have been thinking in reverse for years. Business Architectures must be in place and current in order to make such rapid decisions, and the value of these exercises is most often over looked.
A few notes regarding the maturity of Service Oriented Architecture are worth recording. An area worth discussing is our efforts to carefully plan and design our systems to insulate us from the impact that comes from our business rule changes.
Most maintenance comes from either technology upgrade or business change, hence the need for heightened attention in planning these areas of our system designs and application frameworks. While SOA is the hot topic of the day, it is the “how” that we must carefully watch. Technology and methodology choices will either assist or expose us to volatility in the future.
Languages such as BPEL (Business Process Execution Language for Web Services, should be reviewed and contemplated for use in our designs. It aides us in taking a top-down process approach to SOA. As we prescribed earlier, top down design taking a business rule perspective will be critical in embracing this paradigm shift.
Service Oriented Architecture is ALWAYS business driven, and before we start, we must consider our plan of attack with respect to architecting in the ability to absorb business rule changes.
There has been much in the trades lately about business rule engines, and I’ve personally seen customers build portions of them. Organizations are recognizing their importance and the value within the IT architecture. Tight control and management around the specifications of these business rules is a key area within our IT organizations that one might expect to see elevated in the near future.
If this is so important, and a critical area that we must focus on to manage volatility in the IT Architecture, is it so difficult to get buy in and involvement from the business areas. We find it difficult to get a documented strategy within our organizations, and even harder to find business resources that can be committed to creating models and providing business knowledge.
Often business resources that are committed are not given enough authority, or are taken from areas which do not have the authority to put a stake in the ground and claim that a process has been set and will be respected during system build time. Resources that are not senior executives seem to find resistance into claiming “this is how we do it”.
John Zachman has always reinforced that business activity is what provides the organization’s value chain, and modeling it is well worth the effort. We often don’t get started in the Zachman framework as the Mission and Vision statements are his prescribed starting point at the first level within the planning perspective.
Articles exist on the site prescribing some quick starts if this information isn’t available. See the newest tip, or perhaps one of the articles on this topic. The target and goals should be to answer the most basic questions.
- Who are our customers?
- What services and products do we offer to them?
- How can IT support delivery of these services and products in the most efficient manners, or using technology to exploit a market niche or gain competitive advantage?
Together, these first two questions prescribe how we will deliver value to our customer, therefore providing value back to the business areas. Conversely, answering the latter two questions demonstrate how we will achieve value from the business architecture within the IT Architectures – doing the right things to create winning solutions.
Artifacts such as business process diagrams, system functionality matrices, state and activity diagrams as well as use case and class diagrams are the things we must focus on. We don’t ever seem to get here because of lack of resources, appropriate level of support and focus, nor the understanding of the true value that will be achieved.
These models will allow us to project quickly the potential impacts and reduce costs related to business rule and process changes. It takes dedication to push for resources and project budgets to adequately model these architectures, but I promise – the investment will pay for itself many times over
It’s common for me to answer almost the same questions in many different ways – it is definitely time for some food for thought about one common theme.
The theme is that many budding architects understand the basic architecture domains, and now see that the value may lie in the business architecture. Getting started is another story.
“It’s just Business”, as the saying goes, and it just seems so difficult to complete this part of our architectures. I’ve added more content this week to the Business Architecture section, and will try to keep that flow going. In the meantime, let’s put some content into this eZine.
One of the most reusable asset of your IT environment is the business architecture and the models and artifacts collected to build it. It is also the area which is most vulnerable to change, and the business rules contained within your systems and applications are the most volatile.
The Process Architecture of an Organization is an expression of the hierarchy of process and the sequences within and between those processes. There is a natural progression from process and function identification to procedure definition that may be followed. The Process Architecture should be held at the set / subset level of abstraction. Process Architecture may/should be mapped to business domains.
The Process Architecture of an Organization is an expression of the hierarchy of process and the sequences within and between those processes. There is a natural progression from process and function identification to procedure definition that may be followed. The Process Architecture should be held at the set / subset level of abstraction.
Process Ordering
- Sequence
- Repetition
- Alternation
- Recursion
- Concurrency
A Process Architecture is a hierarchy of processes, functions, and procedures.
A brief description of the main components of an Enterprise Architecture:
The following are components of an Enterprise Architecture. Each individual component is part of the Framework.
1. The business architecture component analyzes the company’s business drivers, opportunities, goals, objectives, and strategies. For instance, does the company plan to develop new product lines, infiltrate new markets, and reduce operating costs, or increase customer satisfaction and loyalty? What are the most critical business problems or opportunities? The business-architecture model also provides a high-level blueprint of all critical business events and processes, along with a description of their relationships and interdependencies.
2. The organizational architecture entails a comprehensive examination of current IT processes, services, organizational structures, roles and responsibilities, and core competencies. All these components are carefully analyzed to see how well they facilitate the creation of flexible application and technical architectures that can quickly adapt to support new business requirements. It may also be referred to as the operational architecture by some.
It addresses fundamental questions such as: How well are IT services managed? How well the IT organization does contributes to the overall enterprise’s success? Are IT services closely aligned with the business strategy? Is the current IT technology infrastructure a barrier to supporting or expanding business?
3. The application architecture lays down the core business applications required to enable business processes and successfully run the business. The application architecture model encompasses all legacy systems, software packages, and distributed systems, along with an appraisal of their strategic value and impact on the business.It also identifies the new applications that are required to satisfy up-and-coming business needs. An assessment of the health of current applications is equally important to include, Fournier says, both from a functional and technical standpoint. Finally, the application architecture must carefully analyze the interdependencies and interoperability needs that are required between business applications.
4. The information architecture examines the key information assets of the enterprise. What are the types, locations, and timing of information that are required to achieve the prime objectives laid out in the enterprise business plans and processes? What types of information need to be shared? In what state is operational and informational data? The creation of the information architecture model also encompasses building an inventory for all operational files, databases, data warehouses, and data marts that are required by current and planned business applications.
5. The technical architecture model scrutinizes the underlying technologies that are required to run the applications, such as computing platforms, networks, operating systems, database management systems, storage devices, and middleware. The technical architecture model can be broken down into specific sub-models, such as platforms, networks, security, and more. For example, some companies have developed a comprehensive security architecture blueprint to enable e-commerce in a secure fashion. Throughout the construction of the technical architecture model, potentially overlapping or incompatible technologies are identified, and those that do not make the grade become candidates for being phased out.
The Deployment Architecture of an Organization is a pictorial representation of the places of the Organization. This can be thought of in terms of distribution, district offices, and technically as network nodes.
When creating a business architecture, one needs a starting place. Here are a few examples of ways to examine and explore Business information in order to create the architecture. Here, the organization means the Enterprise, Company or Organizational Body.
- Organization to Process
- Organization to Data
- Organization to Deployment
- Process to Data
- Process to Deployment
- Data to Deployment
Do they Finally Get It?
“By 2008, 40% of enterprise architects will have primary expertise in business strategy or process engineering” 2004 Meta Group, Inc.
They get it. It took some time, but they get it now. I might generalize and say that most medium size businesses have some sort of architecture function in their midst. I’d go further an say every large business now believes that architecture is the brass ring as far as IT success is concerned.
Why is that? Some might argue that that SOX and Clinger-Cohen in the United States have enacted regulations that force this issue. Others might just say that the world has become technical enough to demand it. Or, we’ve got enough airplane magazines now that use the word.
Let’s be optimistic here – we, as IT professionals finally get it, and that is why. What do we get? That Business drives IT. Period. End of sentence. Business strategy drives enterprise architecture, and business is the pure and simple reason that IT exists in the first place. Enterprise architecture success is determined by corporate and line-of-business managers support.
We have started to group our IT product catalog around services. We have application, technology and operational service portfolios that contact web products such as applications, frameworks, web and internet hosting, as well as customer support. Components are groups into services in each portfolio rather than around business applications.
We are starting to understand leverage and reuse. We are getting a spot at the dinner table when the family discusses business strategy. If we are complete, we will ensure that we have some definition within our IT house walls, of the organization’s environment, its goals, objectives, major programs of action and the resource allocation choices required to execute them.
We seem to understand integration…
An integrated strategy which includes technology is enabling businesses to gain successes as never seen before. When we listen to what the business is trying to achieve, and find ways to enable their desires through technology and they can see it, we are viewed as both compliant and successful. If we are to show up at the dinner table and talk only about new cool technologies, our stock continues to tumble.
Business Executives always go back to the basics when considering strategies. They look at perspectives such as product differentiation and marketing segmentation when considering new strategies. If we can enable them to reach new levels with the use of technology, and speak to how we can help them to arrive at these goals in their terms, they understand, accept and encourage us.
Learn Business Speak
We, as enterprise architects, need to truly understand more business speak. If you are the architect in a commercial setting, take the time to understand some basics. For example, market factors are an excellent area of business knowledge worth knowing. If you spend as some time this month researching various marketing factors such as market entry, product risk, product differentiation and product price positioning in relation to the types of technologies that might be required to implement such strategies, you will have well spent your reading and research time.
I would suggest you spend some time looking at various business decision making techniques, such as Boston Consulting Group’s Product Portfolio Analysis and Porter’s Five Forces Analysis. I’ve spent time studying and using many such models and techniques when I’ve both analyzed and modeled business architectures and share some of this information at my decision making site.
Strategic planning considers business strategic value of IT investments. Learning business strategy yourself will payoff in spades to your future. It is something that may not interest you in theory initially, but when you understand how it relates to technology, you might become much more interested and your stake value will increase dramatically!
– A reprint of an Architect Abstract newsletter article