Aggregated enterprise architecture wisdom
The social media evolution, mobile device proliferation and commodity consumer technology solutions are fundamentally changing the way we interact with each other, shop, browse, read, work, play and plenty more. But will it change how we educate formal…
 |
| What rules of thumb guide your EA efforts? (photo credit: Sanna R) |
When proposing a tool for use in an enterprise architecting project, one should ask oneself “Will I use this tool for analyzing my own business?”. If not, why is it being used in that project? When I was working at Oracle, the company “forced” employees to use software tools made by the company, ranging from employee directories to collaboration tools to software development environments. This “eat your own dog food” culture helped Oracle employees understand the strengths and weaknesses of the company’s offerings, and thus be better positioned to improve those tools. In the same way, enterprise architects should eat their own dog food, applying tools they advocate to their own enterprises, which can range from their family businesses, their social clubs, their churches and even their personal lives (think “Me Inc.”).
During the exercise, I wanted to show the organization how an enterprise architecting tool can bring value to what they do. I decided to try the tool on my own life first: I used it to map out my strategic objectives, and then linked it down to processes in my life (i.e. habits), and eventually connected processes with their supporting technologies (see post on “Architecture of my life“). The exercise helped me see that doing the exercise with the tool created more meaningful artifacts comparing to doing the same in Microsoft Word or PowerPoint. Subsequently, I was able to transfer that insight in my recommendations to the organization.
Enterprise architecting involves many meetings: interviews with stakeholders, internal information sharing, brainstorming, constructing future architectures, etc. Good tools and venue play an important part to the successes of these meetings. As such, it is crucial that considerable thought be given to these two items.
In our exercise, two tools that proved extremely valuable were Google Docs and post-it notes. Google Docs allow all meeting participants to look at the same document at the same time, and also to edit it simultaneously. It helped all the participants to stay engaged, as they are empowered to make changes. We often voiced our opinions by making changes to the document and then asking, “how does this look?” which sped things up as we were discussing and creating the deliverable at the same time. We collaborated in this way even when we were physically in the same room!
The other valuable tool is post-it notes, which is a must have for brainstorming sessions. The key strength of post-it notes is it enables a group to capture individual ideas first, and then later categorize and sequence the ideas, which is hard to do on a single piece of paper or electronic document. We also created an electronic version of post-it notes by using PowerPoint in Google Docs. We created small, yellow text boxes and used them as post-it notes. Google Docs’ functionalities allowed all participants to simultaneously create and edit the “post-it notes”.
As for venue, we had a brainstorming session at a pub and that made the exercise more fun and relaxing. Having a venue with a big screen is also helpful in making sure that everybody is on the same page. In addition, we experienced difficulty in collaborating with our clients who were stationed in a different location. We could not involve them to brainstorm the way we did among ourselves. This challenge was made harder as our clients could not use Google Docs or collaborate with us using physical post-it notes.
In creating the to-be architecture, set aside a time to generate ideas, when none of the suggestions are discarded or criticized; and a time to kill ideas, when all ideas except one are bad. This heuristic helps the team in two ways: in the first phase, the team is able to cover as many possibilities as possible, since all suggestions are captured and considered. Next, in the second phase, the team is able to converge on a single idea, as they systematically shoot down options. A common trap is to bypass or speed through the first phase and jump to the second phase.
I learnt from this exercise a useful approach to separate these two phases: first brainstorm for ideas, group them into concepts, and then slowly converge those concepts by creating candidate architectures before finally selecting a single to-be architecture. I had earlier made the error of bypassing the first phase by jumping straight to creating candidate architectures. I saw the value of the idea generation phase since it allows small ideas (e.g. have a beer drinking session every week) to be captured, even though they do not have enough scope to qualify as a candidate architecture.
Having a systematic approach to converging is also very useful. I saw a useful approach from another team, where they did scoring on their concepts and then select the highest scoring ones to create candidate architectures.
It is really difficult to create the to-be architecture without knowing the next level details. Often, there are constraints on the ground that make the architecture unrealistic. For example, in our exercise, we wanted to recommend a re-organization but later we realized that a re-organization happened recently and thus another one would face more resistance. Another example is when we made recommendations on knowledge management. After we found out about the organization’s existing knowledge management efforts, we realized that one of the difficulties the organization faced was the existence of multiple knowledge repositories. We subsequently amended our to-be architecture to stress the importance of a single knowledge repository. As such, it is important to chart out the next level details when creating the to-be architecture.
How deep into the details does one have to go? I rely on the analogy of building a house: as long as there are sufficient beams to support the house, the house should be okay. So go down to the level of “beams”, which are key elements in the organization that will make the architecture work, and I suspect that differ from organization to organization.
While creating the candidate architectures, my teammates proposed ideas that at that time I felt were infeasible, for I thought they were either too theoretical or things that the organization was already doing. What surprised me was our sponsors liked those ideas, and slowly I too grew to appreciate their values. Eventually those ideas were incorporated into our recommended to-be architecture.
My lesson learnt is that I am a blind man too, as my understanding of our target organization is similar to the blind men’s understanding of the elephant—incomplete and flawed in many ways. I needed to rely on other blind men to tell me that the elephant has a tail, a big ear, and legs as thick as tree trunks. As such, do not shoot down ideas too early, hear what others think of them, and remind yourself that you are a blind man too.
When creating the to-be architecture, it is very important to get buy-in of the architecture, as some of them will be implementing it, and some of them will have power to kill it. The ideal case is really when key stakeholders feel that the to-be architecture was their idea. The approach we took to achieve buy-in was to firstly involve the stakeholders as much as possible in the to-be architecture creation process—from evaluation criteria creation, to idea generation, to the eventual selection of the to-be architecture—so that the organization will not see the recommendations as coming from the outside but rather proposed from within. In addition, we got everybody—both the MIT team as well as people from the organization—to propose ideas and put all the ideas in a common pool, consciously not tagging any names to those ideas. The intent was so that people lose track of who came up with what idea, and hopefully find it easier to identify with selected ideas, and in some cases even think that it was their idea.
Big data seems to be popping up everywhere. The focus seems to be on the data and the engines and all the shiny toys for doing the analysis. However the tricky part is often getting hold of the slippery stuff in the first place.In the cryptography worl…
This posting was written in response to Eric Brewer’s excellent piece entitled CAP Twelve Years Later: How the “Rules” Have ChangedI have copied the statement of the theorem here to provide some context:The CAP theorem states that any networked shared-…
I have been spending a lot of time thinking about Application Architecture in the context of EA. More specifically, as an Enterprise Architect, what do I need to consider when looking at/defining/designing the Application Architecture Domain?
There are several definitions of Application Architecture. TOGAF says “The objective here [in Application Architecture] is to define the major kinds of application system necessary to process the data and support the business”. FEA says the Application Architecture “Defines the applications needed to manage the data and support the business functions”.
I agree with these definitions. They reflect what the Application Architecture domain does. However, they need to be decomposed to be practical.
I find it useful to define a set of views into the Application Architecture domain. These views reflect what an EA needs to consider when working with/in the Applications Architecture domain. These viewpoints are, at a high level:
Capability View: This view reflects how applications alignment with business capabilities. It is a super set of the following views when viewed in aggregate. By looking at the Application Architecture domain in terms of the business capabilities it supports, you get a good perspective on how those applications are directly supporting the business.
Technology View: The technology view reflects the underlying technology that makes up the applications. Based on the number of rationalization activities I have seen (more specifically application rationalization), the phrase “complexity equals cost” drives the importance of the technology view, especially when attempting to reduce that complexity through standardization type activities. Some of the technology components to be considered are:
Organization View: Organizations are comprised of people and those people use applications to do their jobs. Trying to define the application architecture domain without taking the organization that will use/fund/change it into consideration is like trying to design a car without thinking about who will drive it (i.e. you may end up building a formula 1 car for a family of 5 that is really looking for a minivan). This view reflects the people aspect of the application. It includes:
Information View: Whether or not you subscribe to the view that “information drives the enterprise”, it is a fact that information is critical. The management, creation, and organization of that information are primary functions of enterprise applications. This view reflects how the applications are tied to information (or at a higher level – how the Application Architecture domain relates to the Information Architecture domain). It includes:
Application Service View: Organizations today are striving to be more agile. As an EA, I need to provide an architecture that supports this agility. One of the primary ways to achieve the required agility in the application architecture domain is through the use of ‘services’ (think SOA, web services, etc.). Whether it is through building applications from the ground up utilizing services, service enabling an existing application, or buying applications that are already ‘service enabled’, compartmentalizing application functions for re-use helps enable flexibility in the use of those applications in support of the required business agility. The applications service view consists of:
Delivery Model View: It is hard to talk about EA today without hearing the terms ‘cloud’ or shared services. Organizations are looking at the ways their applications are delivered for several reasons, to reduce cost (both CAPEX and OPEX), to improve agility (time to market as an example), etc. From an EA perspective, where/how an application is deployed has impacts on the overall enterprise architecture. From integration concerns to SLA requirements to security and compliance issues, the Enterprise Architect needs to factor in how applications are delivered when designing the Enterprise Architecture. This view reflects how applications are delivered to end-users. The delivery model view consists of different types of delivery mechanisms/deployment options for applications:
While by no means comprehensive, I find that applying these views to the application domain gives a good understanding of what an EA needs to consider when effecting changes to the Application Architecture domain.
Finally, the application architecture domain is one of several architecture domains that an EA must consider when developing an overall Enterprise Architecture. The Oracle Enterprise Architecture Framework defines four Primary domains: Business Architecture, Application Architecture, Information Architecture, and Technology Architecture.
Each domain links to the others either directly or indirectly at some point. Oracle links them at a high level as follows:
Business Capabilities and/or Business Processes (Business Architecture), links to the Applications that enable the capability/process (Applications Architecture – COTS, Custom), links to the Information Assets managed/maintained by the Applications (Information Architecture), links to the technology infrastructure upon which all this runs (Technology Architecture – integration, security, BI/DW, DB infrastructure, deployment model).
There are however, times when the EA needs to narrow focus to a particular domain for some period of time. These views help me to do just that.
I recently had a discussion around who should own an organization’s Enterprise Architecture. It was spawned by an article titled “Busting CIO Myths” in CIO magazine1 where the author interviewed Jeanne Ross, director of MIT’s Center for Information Systems Research and co-author of books on enterprise architecture, governance and IT value.
In the article Jeanne states that companies need to acknowledge that “architecture says everything about how the company is going to function, operate, and grow; the only person who can own that is the CEO”. “If the CEO doesn’t accept that role, there really can be no architecture.”
The first question that came up when talking about ownership was whether you are talking about a person, role, or organization (there are pros and cons to each, but in general, I like to assign accountability to as few people as possible). After much thought and discussion, I came to the conclusion that we were answering the wrong question. Instead of talking about ownership we were talking about responsibility and accountability, and the answer varies depending on the particular role of the organization’s Enterprise Architecture and the activities of the enterprise architect(s).
Instead of looking at just who owns the architecture, think about what the person/role/organization should do. This is one possible scenario (thanks to Bob Covington):
While there are many more roles and responsibilities than listed here, it starts to provide a clearer understanding of ‘ownership’. Now back to Jeanne’s statement that the CEO should own the architecture. If you agree with the statement about what the architecture is (and I do agree), then ultimately the CEO does need to own it.
However, what we ended up with was not really ownership, but more statements around roles and responsibilities tied to aspects of the enterprise architecture. You can debate the semantics of ownership vs. responsibility and accountability, but in the end the important thing is to come to a clearer understanding that is easily communicated (and hopefully measured) around the question “Who owns the Enterprise Architecture”.
The next logical step . . . create a RACI matrix that details the findings . . . but that is a step that each organization needs to do on their own as it will vary based on current EA maturity, company culture, and a variety of other factors.
Who ‘owns’ the Enterprise Architecture in your organization?
1 CIO Magazine Article (Busting CIO Myths): http://www.cio.com/article/704943/Busting_CIO_Myths
Continuing down the life architecture path (photo credit: .:Adry:.)My earlier post Architecture of my life generated a lot of interest, which was encouraging, but it also stressed me to follow up with updates as many readers asked for that. …
I ran across a very interesting op-ed by Tim Jackson on productivity today in the New York Times. The gist of his well-articulated argument is that due to our relentless drive for increased output, certain professions and their attendant tasks…
In this “insane graphic” featured in an article in Business Insider’s article titled “This INSANE Graphic Shows How Ludicrously Complicated Social Media Marketing Is Now” – opened my eyes to just how large the Social Computing Landscape really is …
Metrics guide our actions (photo credit: stefan)(this article is part of the series “12 Heuristics for Enterprise Architecting”)How can an organization recognize progress without appropriate metrics? Metrics are helpful in assessing if the organi…
(this article is part of the series “12 Heuristics for Enterprise Architecting“)
 |
| Stop parroting me! (photo credit: Ferran Pestaña) |
In some ways, the “as-is” phase of enterprise architecting exercises do not generate new content. It brings together observations from different parts of the organization and synthesizes them. Though the synthesis often produce “fresh” insights, these insights might seem obvious to the organization in retrospect, as they are often associated with pains that the organization has been suffering under. In our EA exercise, we received feedback on our “as-is” analysis that ranged from being “spot on” to “echoing back what I told you”, and that seem confusing until we sat down and analyzed the issue.
Learning from this experience, we could have explained to the organization why the EA team was not simply echoing back to them using the earlier mentioned logic. What we did do was to explain to them the EA methodology, and how we relied on it to systematically analyze the organization.
A pretty BMW car. photo credit: marco_dmoz Physical Models: Powerful visual cues for enabling better communicationsBMW’s innovation centre in Munich is designed with deep considerations on how to encourage innovation and collaborations between …