“What Is Enterprise Architecture?” Presented by Stephen F. Heffner

Zintro Webinar

Presented by Stephen F. Heffner, President – XTRAN, LLC.

Presenter’s Note:
“Although enterprises have had architectures since the dawn of time, the study and discipline of Enterprise Architecture is relatively young. So what is an Enterprise Architecture? What are the Enterprise Architect’s duties? Where should the EA be positioned in the enterprise? This Webinar will address those questions and will take a look at the implications of the answers.

About Stephen F. Heffner:
Stephen F. Heffner has been an enterprise/systems architect since 1964, an international consultant since 1972, a software entrepreneur since 1977, a Wharton professor from 1983 to 1994, and an Expert Witness. He is the creator of XTRAN, an expert system / meta-tool for automating the assessment, transformation, and translation of computer languages, data, and text.

Do you have a suggestion for a webinar topic or presenter?

Let us know

Would you like to discuss an idea with our Business Development team?

Fill out our Business Development contact form and let us know.

Are you looking for an Expertise Provider for a Project, Job or Consultation?

Other useful links

 

Transcript:

Enrique: Hello and welcome. My name is Enrique Levin, Co-founder of VP of Product at Zintro. Zintro is a global online marketplace that helps connect companies with highly specialized consultants and other expertise providers for projects that range from one-hour phone consults to multi-month onsite engagements and even full-time jobs.

Today’s webinar, What is Enterprise Architecture, will be presented by Stephen F. Heffner, President at XTRAN, LLC. Stephen has been an enterprise system architect since 1964, an international consultant since 1972, a software entrepreneur since 1977, a Wharton professor from 1983 to 1994, and an expert witness as well.

He’s the creator of XTRAN, an expert system meta-data tool for automating the assessment, transformation, and translation of computer languages, data, and text. If you would like to ask Steve any specific questions throughout the presentation, feel free to use the question section of your GoToWebinar control panel. Click on the little orange arrow on the top-right corner of your screen and you will see the question section. Feel free to ask any question during the presentation. Stephen will be responding to these questions after we finish the webinar.

We will provide his contact information at the end of this webinar for follow-ups, so stay tuned. Without further ado, I’d like to turn it over to our presenter, Stephen F. Heffner.

Stephen: Thank you, Enrique. Welcome everybody. What we’re going to be talking about today is enterprise architecture and what is it. Who is the enterprise architect, and what does he or she do?

Now first of all what do we mean by an enterprise’s architecture? There are a lot of definitions, here’s mine. I define the architecture of an enterprise as the structure of the enterprise’s data, plus the structure of its processes, plus the interactions between the two informed by the enterprise’s goals and objectives.

Now there are a couple of interesting things about this. First of all, this is a very meta definition. That is this applies to essentially any enterprise. In my view the architecture of an enterprise has more in common with other enterprises than it has differences, even when the enterprises themselves are very, very different.

Now for those of you who are familiar with the Zachman Framework, which is essentially what John Zachman calls an ontology for enterprise architecture, and I agree with him. I actually arrived at my definition of an enterprise’s architecture before happening across the Zachman Framework. But it turns out to fit very neatly into it. If you look at the framework, the columns are areas of concern. And the rows are levels of instantiation from very abstract to fully substantiated. Going across the columns the data is his column one. The processes are his columns two to five, which cover various aspects of processes, like what and who and where and so forth. And then the goals and objectives of the enterprise are his column six, which is his why column. Why are we doing all this?

Okay, what don’t we mean by an enterprise architecture? First of all it’s not just IT, although it includes IT, of course, as a major stakeholder. There is some confusion about this, because frequently enterprise architects come up through IT. There is a number of reasons for that. One of them is that the skills and abilities needed for enterprise architecture are most often taught and learned in the IT realm.

Number two, it isn’t just transformation. And by transformation I mean changes to the enterprise, including solutions, although it does play a very important role in transforming the enterprise. And when the enterprise architect rationalizes the scheme of the enterprise, and both in terms of data and in terms of processes, that often exposes transformations that need to be done. And as we will see, the enterprise architect plays a role in that, but is not directly responsible for those changes.

Another misconception about enterprise architecture is that it’s the entire enterprise, including its strategy. I’ve even heard people say, “Well, the ultimate enterprise architect is actually the CEO,” which I don’t agree with. The CEO is not trained as an enterprise architect among other things. And besides, the CEO has lots of other things that he or she needs to do.

But of course, the enterprise architecture plays a vital role across the enterprise, top to bottom, side to side, in every nook and cranny. And of course that includes a very important role in the formulation of its strategy. This is because the enterprise’s architecture provides the architectural base on which that strategy is devised and implemented.

So we’ve got three misconceptions. It isn’t just IT. It’s not transformation. And it’s not the entire enterprise. Unfortunately these misconceptions are fairly widespread, and in my opinion any one of them will doom EA’s chances of success.

So what does an enterprise architect do? Well, if you’re talking about a startup, a Greenfield opportunity, then the enterprise’s architecture has to be created. But for everybody else, where we’ve got an existing enterprise, it already has an architecture. For good or ill, well done or not, rationalized or not, documented or not, it’s there. So typically, when an enterprise architect, entering a new situation, will find an architecture already there and need to deal with it.

The first thing that the architect must do is document the architecture. You can’t very well deal with something if you don’t know what it is. So we want to document it, and there are lots of different ways to do that. That means documenting the data, documenting the processes, documenting their interactions. And by the way, you might remember from my definition, we’re more interested in the structure of the data and the structure of the processes, and how those structures interact than we are in the details of the data and the processes. That’s one reason why I said that the architecture of one enterprise is much more similar to the architecture of another one than it is different. Because we’re dealing in structural terms, not in the details.

So once we’ve got it documented, the next thing to do is rationalize it. We start with an entity relationship analysis. And for those of you from the database world, you’ll know exactly what I’m talking about there. It’s basically an analysis of what are the major entities in your data. What are their attributes? And what are their relationships to each other? That gets you an enterprise schema.

The next thing is to look at the process structure and rationalize that using the enterprise schema as the base. Now this is analogous to normalizing a data schema, if you’ve got for example a relational database. We want to eliminate duplication. We want to make sure that replication is carefully controlled and synchronized and so forth and so on.

Okay, once we’ve got our architecture documented and rationalized, the next thing to do is to go through it and make sure that it is optimized to serve the enterprise’s goals and objectives as effectively as possible. This is critical. It isn’t enough to just say, well, we’ve got an architecture and there it sits. That architecture has to serve what the enterprise is there to do.

And by the way, this also addresses a question that often arises about enterprise architecture being too ivory tower and not really related to the business and so forth and so on. Well, it couldn’t be further from the truth. If you think about enterprise architecture pervading every nook and cranny of the enterprise, effecting and being affected by pretty much everything that goes on throughout the enterprise, and being optimized in terms of what the enterprise is trying to do. That’s about as business oriented an as un-ivory tower as you could possibly get. And that’s the way it needs to be. As we’ll see, that actually has even further implications in terms of the reach of enterprise architecture through the enterprise.

So we’re got our architecture optimized, but things change. And there are two main sources of change. One of them is the goals and objectives of the enterprise may change. This may be a business issue. It may be a strategy issue, although strategy usually comes from goals and objectives. But sometimes it works the other way. And of course there are often external changes; for example, if the enterprise is in a regulated industry those regulations change. Also events have implications for the enterprise as well; natural disasters, changes in the market trends and so forth and so on. Okay, so the enterprise architect has to keep the architecture fluid and adaptive to changes that come along.

The next thing is the enterprise architect should be exercising architectural oversight of any material change to the architecture or to anything that affects the architecture. And that must be with veto power, because otherwise it doesn’t have any teeth. And we’ll see what that means about where the enterprise architect should report in a minute.

This architectural oversight is necessary to make sure that the architecture is not compromised. Architectures are constantly under attack from within the enterprise by special interests and people who see things differently. And the enterprise architect has to defend the architecture from that and adapt it as needed, of course, to change.

Another key aspect in my view of an enterprise architect’s responsibilities is to educate the entire enterprise about its own architecture and the critical role that that architecture plays. And I’m not talking about just educating the CXOs. In fact I’m talking about the Board of Directors, the CEO, the CXOs, down to middle management and down into the troops in the trenches, including, believe it or not, the janitor.

Now why do I say that? That sounds kind of strange. The reason is every employee of the enterprise can do a better job and will have better morale if he or she understands what he or she does in terms of the architecture and the role that he or she plays in the enterprise’s goals and objectives and its strategy, and the architecture on which all of that is based. So I actually recommend seminars on a fairly regular basis for all levels of the enterprise in the nature of its architecture and the implications for people’s jobs.

The next thing that the enterprise architect does is provide consulting in-house about the architecture to everybody who has to deal with it. This is from the executive management, who is determining goals and objectives and defining strategy to the various stakeholders in all of the different special interests within the enterprise and the solution architects who are designing and overseeing the implementation of solutions.

And then finally the enterprise architect is the champion and defender of the architecture, because as I mentioned, once an architecture has gotten into good shape, there is constant pressure to de-normalize it in the interests of one project or another, one stakeholder or another and so forth.

So those are the responsibilities that I see for the enterprise architect. And as you can see, looking over that list, you can see that the enterprise architect and his or her team are very active throughout the enterprise, engaged in everything, providing oversight, education, and consulting. It’s a very, very dynamic role, and a very, in my opinion, a very important one.

So in fact it’s so important that in my view the enterprise architect must report directly to the CEO. Now if you look across the landscape, lots of enterprise architects, you’ll find them in IT. You will find them under the CIO. Sometimes you will find them under the Chief Finance Officer, because it all started with bookkeeping and accounting.

That might be where it starts, but that’s not where it should be. Because the enterprise architect’s charter spans the entire enterprise, top to bottom, side to side, every little bit, it means that any report other than to the CEO is going to create a conflict of interest for the enterprise architect and limit the application of the enterprise architecture throughout the enterprise.

This also means that the enterprise architect and his or her practice of enterprise architecture must have the knowledgeable and enthusiastic support of the CEO. If the CEO is enthusiastic but not knowledgeable, then we refer back to the educating responsibilities that the EA has that I mentioned before. If the CEO is knowledgeable but not enthusiastic, we have another problem. It’s going to be difficult to achieve success with enterprise architecture in that particular enterprise.

So you have just been hired as an enterprise architect in some enterprise somewhere. And you arrive and you need to know what kind of shape they’re in in terms of their architecture. So the first thing you should do is an assessment. And here are the main things you should be looking for. Number one, what is the quality of that architecture? Obviously, if it’s not documented you have to documented it first. Or if it’s poorly documented, you need to get it up to snuff.

So what is its quality? By quality I mean is itself consistent? Is it rationalized? How robust is it in the face of change? And by the way, another thing that goes with robustness is agility. In my view, a rationalized and optimized enterprise architecture is inherently agile, meaning that because of the nature, the level of its abstraction, it can respond quickly to changes from the external environment or from the goals and objectives of the enterprise.

And in fact, it even promotes agility throughout the enterprise, because all of the operations of the enterprise are based on something that makes sense and is consistent, and well understood.

The next thing is you can have an enterprise that’s very high quality, very robust, but it doesn’t happen to fit the enterprise’s goals and objectives. In other words, it’s pointed in the wrong direction. So we want to make sure that the architecture is fit to serve what the enterprise is trying to do.

And another thing that’s important to notice in a particular enterprise is how critical is its architecture to the goals and objectives of the organization. This varies, now in my opinion it’s always important, because it’s the base on which the enterprise does everything. But in some enterprises that are very action oriented the architecture will play a less central role, I guess I would say, than in others.

For example, if your business is fighting oil well fires. You’re the Red Adair of oil wells. Your main job is to get out there and put the fires out. Now you need a good enterprise architecture on which to do that. But the architecture is not the soul of the business that you’re in. On the other hand if you are in the let’s say big six accounting business, then the architecture is more central because your whole enterprise’s activities are based on data and the manipulation of data.

So there is some variation in terms of how critical the enterprise architecture is to what the enterprise is trying to do. Although as I said, in every enterprise it is critical in the sense that if you don’t have a good one, things are going to go badly.

Okay, let me go back. Okay, so you’ve done your assessment, and you realize that things are already exactly where you would like for them to be. So how do you make sure that everything is up to snuff? How do you remediate the situation to get it to the point where you want it?

Well the first thing you want to do, and this really follows from my definition of an enterprise’s architecture and the duties of the enterprise architect. The first thing you need to do is make sure that there is a current and up-to-date entity relationship analysis of the enterprise’s data. Make sure that it’s normalized, and that includes the elimination of synonyms and homonyms. This is very important. Synonyms are different terms for the same entity or attribute. Homonyms are the same term for different entities and attributes. And both of them cause confusion.

Now you typically find them in silos. Most enterprises that have been around for a while have silos. They have vertical special interests, if you will, or areas of concern. And oftentimes what will happen is that each of those silos will develop its own jargon for what the enterprise is dealing with. This obviously is not a good idea, because we don’t have everybody talking the same language. So that’s important.

Also, make sure that there is a current and well-done structure analysis of the enterprise’s processes as well. And then a current mapping of the process structure onto the data structure. Because you may recall that I defined the enterprise’s architecture as the structure of the data, the structure of processes, and the interaction between those two sets of structures; plus, of course, being optimized to best serve what the enterprise is trying to do. And that one is the last one. We want to make sure that the architecture is optimized to in terms of the goals and objectives that the enterprise is trying to accomplish.

So how do we deploy this? Well, and this is a good checklist if you’re coming into an enterprise that doesn’t have an active enterprise architecture practice. It has an architecture, of course, but it may be chaotic, because things may not have been controlled very well.

So the first thing we want to do is we want to take a look at the process structures, and normalize them analogously to normalizing the data schema. We’re looking for duplication of effort. We’re looking for objectives that conflict with each other. And we have to redesign the processes and their structure to eliminate that.

Now by the way, you might remember that I mentioned that this process will unearth transformations that need to be made. That’s particularly true of this step. So this is going to make clear some changes that need to be made, and it’s important that although the enterprise architect should oversee those changes on behalf of the architecture, he or she should not be directly responsible for them.

And then interpret and optimize the architecture in terms of what the enterprise is supposed to do. Take a look at the existing portfolio of solutions. Now this will be both solutions that exist, and those that are due for change, and maybe some new ones that people have in the pipeline. This is the infamous backlog of solutions that just about every enterprise of any size has.

So those solutions need to be reviewed in terms of the architecture. That’s actually done in cooperation with solution architects, with the enterprise architect providing oversight and consulting to them on the enterprise’s architecture, and working with them to do the review.

And then take a look at what’s in the pipeline as well, which I just alluded to, proposed enhancements, additional functionality that people want. And make sure that those are in line with the goals and objectives, the strategy that derives from the goals and objectives, and the architecture that derives from the goals and objectives as well. At that point, if all of these things have been done, you should be in pretty good shape.

So let’s take a case study. There was a European automobile company, a large one, whose North American operation was not doing well. In fact it was doing quite badly. An example of that is they were getting less than half of the parts business in North America for their own parts, for their cars. So the main office, the main facility in Europe sent a new CEO over to decide what to do with the North American subsidiary. And his mission was to either salvage it, if possible, or liquidate it if it couldn’t be saved.

He hired a three-consultant team, of whom I was one, to do a full audit of their architecture, and their IT operations. Because they knew they had problems in IT, but they didn’t know whether that was the extent of it or if it reached further throughout their enterprise.

So we were given a conference room and we did interviews at every level of the organization, the CEO, the CIO, a couple of the other CXOs, middle management, and all the way down to key-punch operators. We did a rough entity relationship analysis to find out what the major entities were in the data schema so that we had a good idea of the lay of the land, if you will, in terms of the data structure throughout the enterprise. We did not have the time or charter to do a full-blown E.R., nor a full-blown enterprise architecture rejuvenation. We were there to find out what kind of shape things were in. We used our interviews to explore the process structure of the enterprise as well.

What we found was that the architecture of this particular operation was fragmented among silos. And in fact, even within IT we found fragmentation in silos, which gives you an idea of how things had gone up to that point.

So we recommended, number one, to consolidate and rationalize the enterprise schema. And then looking at the process side of things, kill half of the existing IT projects that were underway. Go through the remaining half and clean them up, because some of them needed some significant changes. And by the way, fire the CIO, because he was causing a lot of the problems. And the CEO, who had been brought over from Europe, actually accepted and implemented all of our recommendations. As a result of that, that operation over a period of years after that came back to pretty good health. And they actually recaptured a significant market share in terms of the parts for their own automobiles in the North American market as well.

So at this point I’m going to turn it over to Enrique for questions and answers that you folks may have submitted during the session. And I’ll be glad to entertain those.

Enrique: Great, thank you very much, Stephen. And thank you everyone for attending. This closes the presentation, and now we’re going to move on to answering questions. Feel free to use the question section of your GoToWebinar platform to send Stephen any specific questions you would like answered.

We’re going to start with a question from Osama. His question is what is the relation of EA to quality management?

Stephen: A very good question. First of all, remember that I mentioned that the enterprise’s architecture is the base on which the enterprise’s activities are built. So it must be of very quality. Now interestingly enough, because the enterprise architecture pervades the enterprise, top to bottom, side to side, its quality assists quality engineers throughout the enterprise who are enhancing quality in what they do and what they’re responsible for. And it also makes it even possible, by the way, because if you’ve got a low-quality architecture underneath you, it’s difficult to do high-quality work. You’re on a faulty base.

So I would say that there are two aspects to that relationship, Osama. One of them is that the quality of the architecture pervades the enterprise, sets standards for quality throughout the enterprise, and gets everybody pretty much on the same page in terms of the need for quality. That’s point number one.

Point number two is it enables quality in terms of data and processes and human activities throughout the enterprise as well. Quality engineers, quality assurance architects and engineers, interact with the architecture constantly as a result of what they do. So in my view the enterprise architect and his or her team should be very active working with the QA people to coordinate quality at every level of the enterprise.

Enrique: Thank you very much, Stephen. We have another question by Mohammed. The question is does it mean that EA can use a transcript of different scenarios and its reflective different proactive measures that may have been in the future during running of the business? Does this mean that EA can use a transcript of different scenarios and its reflective different proactive measures that may happen in the future during running of the business in different aspects of the business, like production, finance, and marketing within the enterprise? It might be one of the strategic structures of the enterprise.

Stephen: Sure. Okay, Mohammed, first of all that could be useful in the work that EA and his or her team does. But in my view dealing with scenarios and dealing with strategies and operations throughout the enterprise comes for the EA, it comes from the architecture itself, and vice versa. That is, those operations obviously affect the enterprise over a period of time.

In terms of handling changes, it comes up as I mentioned during the presentation. In my view a well-documented, well-rationalized, and well-optimized architecture is inherently agile and robust, which means that it will hold up very well under change and will facilitate changes, in fact.

Now I don’t see the direct application of agile methodologies to an enterprise architecture itself. But it does enable them in the sense that it provides structure. One of the things about agile is that it’s a little light on structure up front by design. And if there’s a really good structure underneath it that helps mitigate that.

So in terms of dealing with change, sure you can propose scenarios, and this is part of what strategists do, of course, what ifs. The role that EA plays in that is to represent the nature of the enterprise’s architecture in that effort . . . not to actually create strategy.

Enrique: Thank you very much for that, Stephen. We have another question by Eric. Eric is asking what basic skill sets lead to being a good enterprise architect? Is it project management? Strategic planning in frameworks?

Stephen: An excellent question. If you think about the nature of the enterprise’s architecture as I define it, obviously an EA must be really good at data analysis, and especially data structure analysis. So a DVAs type of skill set is needed. At the same time the architect must also be very good at analyzing processes. So any kind of background or skills in the area of process analysis and process structure analysis is obviously important. And then synthesizing that obviously takes a depth of experience as well.

In addition to that and something that I didn’t really talk about in the presentation, the enterprise architect must have really good diplomatic skills and people skill, because he or she is representing the architecture throughout the enterprise to every level. That means that the EA must be comfortable talking to the board of directors, and talking to a keypunch operator about what he or she does, every level. That’s unusual. If you look at these various different skills, the ones that you mentioned are sub-sets really of that, and anybody who has got the set of skills that I just described will acquire more detail skills as needed very quickly. There aren’t very many people who can do a good job of enterprise architecture. They don’t grow on trees. That’s why there are never enough good ones.

Enrique: Thanks, Stephen. We have a question by Ron. If the quality of EA is to be maintained, whose job is it?

Stephen: Good question. That is the oversight that I mentioned, Ron. It’s the EA’s job to maintain the quality of the architecture, absolutely. That’s one reason that the EA must have the enthusiastic support of the CEO, because the assaults on the architecture, which could degrade its quality are going to come from special interests. “Let’s de-normalize this part of the architecture, because that would be more convenient for what we do.” Well, usually that means that whoever is proposing that hasn’t done a good functional analysis of what they’re trying to do. And the EA can help them do that, because the EA is very well qualified as a consultant in that area. So the responsibility for the quality architecture rests with the EA, backed up by the CEO.

One thing that I will say about that, by the way, and again this is an area that I didn’t really get into before this. The nature of enterprise architecture, because it’s across all aspects of the enterprise, top to bottom, side to side, and because it provides a common framework, if you will, across the enterprise, an effective EA practice breaks down silos, gets everybody working together as a team, and raises morale, because people understand how they fit into everything. So it actually has very beneficial effects in my view on the management of the enterprise as well, even though that’s not a direct responsibility of the EA, of course. So maintaining that quality is important because that’s the base on which everything is done. And if you start shifting the base, obviously that’s an earthquake, and that’s not a good idea.

Enrique: Okay, so we have a question by Alex. When remediating an enterprise’s architecture if the enterprise has limited previous documentation, should I use the previous documents or start from scratch?

Stephen: Very good question. It will depend on how limited they are, and what kind of quality they are already. Now the problem is, of course, coming in you don’t know that.

So what I would recommend would be an assessment of the current situation, looking for whether or not what’s already been done can be trusted, and is of sufficient quality to go forward with. If so, sure, go ahead and use it as a starting point. If the answer to any of those things is no, then you probably want to start from scratch and do your own entity relationship analysis as the starting point.

By the way, the job that I’m talking about of documenting, for example just documenting the enterprise’s architecture is a daunting task. It’s big. So what I recommend is that the enterprise architect delegate the responsibility for that analysis to those who produce or consume or transform the data, and those who run the processes. That gets back to the education aspect. You need to educate people in enterprise architecture to the point where they can do that job. They don’t have to become enterprise architects, but they have to understand it so that they can feed back to the enterprise architect’s team the necessary information about data and processes that the EA team can then synthesize to document the architecture and then start rationalizing it.

So you divide and conquer. You delegate a lot of that work out to the people who are responsible for the pieces that are being documented. That has another advantage, by the way, because it gives them an emotional investment in the enterprise’s architecture, since they helped. From their point of view they helped build it. And that means that when you have to exercise that architectural oversight I mentioned, it goes down more smoothly than if you had a hostile audience who didn’t think they had anything to do with what you’re talking about.

Enrique: Thanks, Stephen. We have a question that I’ve seen come in from two different people, so I’m going to bring that up. One of them is Gerard and the other one is Mohammed. And so the question is basically how do you define the quality of an enterprise architecture? And Mohammed asks basically, what are the major KPIs of the enterprise architecture?

Stephen: Okay, good question. I think in terms of when I think about the quality of an architecture, first of all, I define an architecture in the most general sense as the structure of a system in terms of its function. And you can see how my definition of an enterprise architecture fits into that. So when we talk about quality, we’re really talking about a number of different things. We’re talking about the quality of the structures. Are they normalized? Do they make sense? Do they work well with each other? And do they make sense in terms of what the enterprise is trying to do? So that’s a level of quality.

There is quality of documentation for example. If you don’t document an enterprise’s architecture in a high-quality way, things are going to go badly from there. So it starts there.

And I don’t know if I can come up with KPIs specifically, but an enterprise architect who has the necessary background and training recognizes quality when he or she sees it and deals with it. And it has to do with consistency, with accommodation of completeness and terseness, if you will, good use of vocabulary.

By vocabulary I mean a taxonomy. All of these are aspects of the architecture and particularly of the data and the processes. There is a taxonomy. That taxonomy derives from an ontology. The ontology is the conceptual framework of the architecture. The taxonomy then is the vocabulary we use to talk about those concepts. And you remember I talked about getting everybody on the same page in terms of that taxonomy, getting rid of homonyms and synonyms, for example. So that’s an area of quality as well.

Enrique: Gerard actually added a comment to that that I would like to read out loud. So he says, “Quality of an EA is directly related to customer expectations. If you don’t measure customer experience as customer outcomes in your EA, then you’re missing the point.”

Stephen: Okay, I would say to that that customer expectations are not the direct business of EA; indirectly, yes. Customer expectations bear upon the goals and the objectives, obviously. The strategies that the enterprise devises to accomplish those goals and objectives, and how those strategies relate to customers and then the actual solutions and implementations with user experience, user interfaces, user access, and so forth and so on. That gets into mobile and cloud and all kinds of stuff.

But the enterprise architect per se is not directly responsible for customer expectations and customer experience. That is a concern that would compromise the enterprise architect’s objectivity and independence in terms of maintaining that architecture in the best shape to achieve all of those things.

So I’m not saying that they’re not important, and I’m not saying that the enterprise architect doesn’t have an effect on them. I’m just saying they are not direct responsibilities, just as solutions are not direct responsibilities of the enterprise architect.

Enrique: Thanks, Stephen. I think that was very clarifying. We have many more questions, but we’re close to running out of time. So I’m going to go with a couple more, and then we’ll close the presentation. We have a question from Rakesh [SP]. So Rakesh basically asks how to make silos function better. And I assume this is when you go into a company and try to create an architecture, or try to improve the architecture. And your architecture might be integrative, but the existing structure is silos. And how can you make them function better?

Stephen: Okay, that’s an excellent question. Silos come from separations of concern originally. Bu then of course they become their own little fiefdom. They have their own political structures, and power struggles, and turf wars, and all kinds of things like that.

So we generally think of silos as bad. But in fact, they serve a purpose, and your question bears directly on that. In my view, number one, the aspects of silos that divide people from one another throughout the enterprise are bad and should be torn down. We don’t want people divided from each other. We want people working together as teams. And the nature of enterprise architecture, as Enrique just mentioned, actually assists that, because it does tear down artificial separations of concern.

At the same time there are legitimate separations of concern, and this bears on your questions about how do you make silos work better. In my view silos work the best when their separations of concern that define them are, number one, legitimate; number two, agreed upon by everybody at all levels.

And number three, well defined. So at that point you’ve got what you could call a silo, but I would call an area of concern rather than using the term silo. They are also called stove pipes, by the way, in the intelligence community. But it’s the same idea.

So enterprise architecture helps each of those separate areas of concern work better, because each of them is working, number one, on a solid base, which is the architecture. And number two, working in cooperation with other areas of concern where they can be done.

One of the things I’ve seen as an enterprise architect over many, many years is that the separations that I find in typical enterprises are mostly artificial, and are getting in the way. So if we tear those down, and we look at the separation of concerns that are legitimate in the enterprise and define them, then we still have COOs and CFOs and CSOs and so forth. We have people who are responsible for those areas of concern, but they understand their relationship to everybody else, other people’s areas of concern, and the entire enterprise and what it’s trying to do, its goals and objectives.

Enrique: Great. Thank you very much, Stephen. Well we’re going to close the Q&A for now. Just remember, feel free to contact Stephen directly with the information provided, or by going to his Zintro profile. And on behalf of Zintro and over 170,000 members, thank you so much for sharing your insights.

This closes today’s presentation. We’ll be posting the video and recording of this presentation in the following week. You should always receive a notification, and if not you can always go to blog.centro.com/webinars to check all of our presentations out.

Also feel free to share them around if you find that anyone could get some value from it. And again, feel free to reach out to Stephen if you have any questions, follow-ups, or would like to engage in any way. Thank you very much everyone, and have a great day.