I was perusing my news feed on LinkedIn the other day and came across yet another definition for “Enterprise Architecture” and “Enterprise Architect”. It was offered by a very high-level person at a very prestigious consulting company. It is full of lofty platitudes, big words, and high aspirations. The discussion that followed consisted of people trying to polish the definitions or to tear them apart.
The whole thing struck me as yet another “ivory tower”, academic pin-head approach. Lot’s of words. Complex sentences. Ambiguous meanings. Disagreement within the “community”.
I offer the following:
An Enterprise Architecture depicts what we are, what we want to be, and the course for how we get from the present to the future. An Enterprise Architect is the cruise activities director.
“What we are” is our present state. It includes business goals and processes, technology goals and processes, and the means to measure each. “Who we want to be” is our future state and contains the same elements. The “course” is a gap analysis for each change we need to make on our voyage.
Why is the Enterprise Architect the activities director instead of the captain? Because the EA is not in charge. He makes interesting activities (migration project) available to the passengers and crew and they decide what they want to do.
The Duality of Enterprise Architecture?
There is a very interesting article that came across my LinkedIn newsfeed today. It came via a “like” by one of my contacts. I can’t tell whether it’s posted to any EA forum. The theme of the piece is duality.
The premise of the piece is that enterprise architects must possess a dual nature because of two vastly different aspects of the job. These facets are the need to be a change agent and the need to be a controller. The post begins with the very familiar lament that EAs are constantly forced to prove their value to their organizations. I think the tenor of this article is that EA and being an enterprise architect is hard and really exhausting.
The article IS well written. So are many other articles with which I disagree.
Why does EA and the enterprise architect have to prove their value to their organization? Most organizations do not pay for functions or for people who don’t add value. The constant need to defend your value proposition must be terribly exhausting. It’s also really perilous. Perhaps it’s because these EA practitioners have an incorrect idea of value. Perhaps they are using a flawed model for their EA practices.
The job of EA is to understand what the business is trying to do and why and then design strategies to get them there. The business leaders have done this for the basic business and for any changes they believe are important. This leads to another question. Why isn’t the enterprise architect among the business leaders? Is it because the enterprise architect is really a senior technologist and not a business management type? I find this to be true in most organizations that don’t have effective EA programs.
Change Agent?
The idea that an enterprise architect is a change agent can really head in a bad direction. I can see the need to justify one’s existence if the changes proposed aren’t resonating with the business leaders. Why in the world would an enterprise architect propose a change that has such shortcomings? Why not work on making those changes the business leaders want happen? Freelancing trying to find changes that resonate with you and trying to sell them to the business leaders is hard. They have other things on their minds.
Most enterprise architects frame every change as a technical problem with a technical solution. Many times an effective enterprise change involves a complex business process. This process has so many exception paths hung on it that nobody knows what the process is really supposed to accomplish. Instead of devising a complex and expensive technical solution, an inexpensive simplification of the process is really all that’s needed.
Controller?
I find the controller facet the most troubling. At this point when the business leaders don’t understand you, you now want to start pushing the technical people around. I think the real problem with our enterprise architect is that he doesn’t have any friends outside of the EA team, if there is such a team.
If your idea of enterprise architecture has the enterprise architect involved in system construction, you’re not working at the enterprise level. You’re working in IT and you’re a systems architect or network architect or applications architect. We need people in all of these roles. What we don’t need is for them to delude themselves into thinking they work at the enterprise level. The only way an architect working in the IT department is working at the enterprise level is when the enterprise is in the IT business. If you work for any other organization with a different business, an IT person is not THE enterprise architect.
In summary, I think this idea of dual nature only serves to complicate EA and the duties of the enterprise architect. If the architect is REALLY working at the enterprise level, he understands what the business leaders need and why. He then works to help make it happen for them by working with other architects in lower levels of the organization and coordinating, not controlling. There’s no need to sell what you’re trying to do because the buyers are already bought in and they trust you to devise the way to make it happen.
BDEA Principles Page added to the Epignosis Web Site
I have added a Business-driven Enterprise Architecture Principles page to the website http://www.temp.epignosis.com.
Last year I wrote a blog post describing my enterprise architecture principles. They were written informally as an essay. I have found myself going back to find them so I can make them available during the time since the post.
I now have formalized these principles, added some points, reworded others, and placed them on their own page. There is a link under the main menu bar that will take you right to them.
I will be writing blog posts to more fully describe my thoughts and put links one the BDEA Principles page so I (and you) can find them easily.
Knowledge Management – Foundational to Enterprise Architecture
I once worked for a company that was in the Mergers & Acquisitions business. Their strategy was to build a large company by acquiring smaller companies and consolidating their operations to save costs. Several teams throughout the organization who responsible for the various projects required to complete the assimilation of each acquisition.
It quickly became apparent to the employees at each acquired company that the consolidation would result in most of the people there losing their jobs. Our company had a team whose job was to move quickly to collect as much knowledge as possible from these people before they left. We documented most of this knowledge using the EVP method (Excel, Visio, PowerPoint). The goal was to quickly learn how the acquired company operated and then pick it up, move it, and operate it in our location. The intent was that the customers wouldn’t notice the difference.
As you can imagine, the architecture of our company changed with each acquisition. We kept our own documentation as the collection of EVP artifacts gathered from each company we acquired. We never integrated these documents and thus our company became harder and harder to manage and never really understood our enterprise or its architecture. Eventually, this lack of understanding lead to management mistakes that ultimately contributed to the demise of the company.
Senior management was running an M&A business. Middle management was trying to run a customer servicing business because the companies we were buying had existing customers that we wanted to leverage and whose products needed to be serviced. The needs of the former drove the complexity of performing the latter through the roof. Our environment devolved into a situation where it took twenty-four months to fully train a customer service representative (CSR). The average tenure expectancy of a CSR was about seven months. Talk about a death spiral!
Management decided to consolidate business onto several strategic platform systems in order to simplify. These projects were very complex. They required often dirty data to be moved into new data structures and business rules embedded deep within very old code bases to be harvested and re-implemented. These physical realities would not be fully documented during the business consolidation efforts that had occurred years prior, the documentation for which may or may not had been readily available. Needless to say, things didn’t always go well. There were times when our new processing deviated from the contractual requirements of the products. This led to numerous lawsuits and distracting litigation.
I formed my views on Enterprise Architecture in this environment and developed my sense that EA must be driven by the business. An enterprise is not a static object. Most are not as dynamic as the one i describe above but they are all constantly changing and adapting to new realities they face daily. There is some business manager in your enterprise who is fighting for his very survival. He really doesn’t care about your big plans to move the enterprise forward in a rational way. He finds you to be totally irrational because you are more worried about your needs than about his.
I am not saying that you shouldn’t try to have some grand plan. I am saying that your plan must account for those daily realities and consider them part of your challenge and not a distraction to your work. In order to do that, you must completely understand your current environment regardless of how it came to be.
This is more of a knowledge management exercise than it is an enterprise architecture exercise. This is a situation not well served by the EVP methods most of us have employed in the past and are probably still using. What we need is a way to quickly gather data about our enterprise and to quickly update it as things change. This data must be integrated and available for analysis. We then need to use it to develop plans that resonate with the business leaders by addressing their needs. EA must become part of the strategic business planning process through its role as curator of knowledge. This will enable the architect to gain a seat at the executive table in order to facilitate change.
Knowledge Management, that’s the fuel for complete understanding.
Know What You’re Buying
I had a conversation earlier this month with a colleague, Marc. He is active in the Enterprise Architecture forums on LinkedIn. Marc asked me to review some material he had developed for a book he is writing. We had been corresponding for a while but we decided to conduct a call for a more free form discussion.
Marc’s work will fill a large void in the book of knowledge for EA. He is working towards definitions of Enterprise and for Enterprise Architecture. I applaud him for his efforts and respect him for the amount of grief he takes on trying to vet his ideas in a forum with worldwide reach. There are many people in the EA world who are too deep into the weeds to have a strategic view of the Enterprise, what it does, and how it should do it. Marc’s book will hopefully re-calibrate those discussions.
One thing became evident in our discussion. Marc and I have different views as to what architecture means. We both use the ideas of structure, architecture, and documentation when we discuss the domain of the Enterprise Architect. I use structure and architecture synonymously to describe the state of the enterprise. I believe the failings of EA to gain traction in many organizations is that the architects are always trying to define the end state while ignoring the current state. You will find more about my thoughts here. The bottom line is I think you need to completely understand your current state before you can move the enterprise to a new place. You gain that understanding from documentation.
Marc understands structure and architecture to be different concepts. Structure is the state. Architecture is the documentation. You can read his work on LinkedIn to get into his development of these ideas.
I don’t think either of us is wrong. I know that our approaches are different. As the buyer of EA services, it is incumbent on you to understand what the practitioner is selling and how he will deliver his work products.
House Cleaning and Catch Up
Sorry to inundate you with posts today. I have been using the WordPress app on my iPad to write these posts and apparently it can’t update the blog on the website. I had to copy and paste the content so I could post it.
I’ll be more timely in the future.
Will the Owner of the System using (Open Source Software Name) please call Security?
The FBI issued a bulletin on February 18, 2016 warning government entities of a ransom ware threat exploiting a security weakness in the JBOSS application server. It appears that versions of JBOSS prior to version 7.0 are affected. Red Hat, the primary support company for JBOSS, verified the fix for the weakness on February 15.
This post is not about bashing the open source movement or Red Hat. This is about understanding the software you are running in your environment.
I work at a government agency that received the notice from the FBI. It caused me to consider the following:
Do we have this vulnerable software running on our network now?
Is it exposed to the outside world?
How did it get there?
How do we remediate if the answer to the first question was yes?
What’s the next potential threat?
The best situation is that you control your technology stack to the point that you already know what is running in your systems environment. If not, it’s pretty easy to find any software package, especially if it’s a Java .jar file as open source software is predominantly. But this does take time. You just set the network scanners to look for it and then read the report. If it shows up on the report, you have a problem. How big a problem?
If it’s used in a system that is exposed to the Internet, you have a big problem because the exploit door is wide open. If the system is buried inside your network and only used by internal users, you are much better off, if you can trust your users to adhere to your organization’s security standards and protocols. You have those in place. Right?
How did it get there? There are two ways: First, your own developers could have introduced it in a software system they wrote. Open source software is great because there is no acquisition (i.e. Licensing) costs and you can find documentation with the package, on the Web, or in a book. It’s also a great way to jump start a project because a big bunch of code is already developed and stable(?). Many developers like to use open source for these reasons. You just need to make sure that they are paying attention to maintenance changes required by their choices and that you provide time to let them make those changes when required. Like now. Or better yet, before now.
The second way to obtain this software is from a vendor. Vendors providing turnkey solutions really fall under the scenario of your internal developers unless you have retained them to maintain your software. The other way is that it was introduced by a vendor with a COTS system. This is a different situation, especially if you are paying for maintenance. You expect that your maintenance contract will provide coverage for problems like this. But here are the issues you could encounter…
First, there must be a remedy available. This is either an executable or .jar (i.e. A patch) or it’s an entirely new version to which you can upgrade. If a remedy is available you have the basis for a plan. If not, you have to deal with the murky world of open source software. I’ll discuss this below. If a remedy is available, your COTS vendor must have the resources to upgrade his code to use the upgraded component and then he must be able to deploy it to you and all of his other customers who are in the same predicament. This takes time and people. Time you may not have. People he might not have. And people you might not have to do the regression testing this change might require.
In the case referenced at the beginning, Red Hat has the resources to provide a remedy and it is available. But what if the package that is vulnerable is not managed by a deep-pocketed open source supporter like Red Hat? What if it’s like the OpenSSL project that’s basically four guys in a garage? OpenSSL is one of the most important technologies on the Web, providing encryption services for over half of all websites. Well, you might have to wait a little longer for that remedy and meanwhile you’re the one sweating it out. What if it’s an abandoned project? You are now on your own. That is the darkest side of open source.
Finally, the question is whether your vendor (or your developers if this is a home-grown system) have the capacity to get your system upgraded before you fall prey to the ransom demand. We talked about the vendor and his challenges already. If you have your own developers supporting this system, it’s probable they’re not just sitting around waiting for things like this to happen. This means they need to disengage from whatever it is that they’re doing now and concentrate onfixing this problem. And timelines slip. Just another day at the office.
What’s the next potential threat? Who knows? There are security firms all over the world who make their livings testing software and working with development teams and organizations to fix security problems. There are also hackers doing the same testing and working with other like-minded people to exploit those vulnerabilities before they are found by the good guys and fixed. The critical period of disintermediation is not between these two events but from the time a vulnerability is found until you have the security fix in place in your systems.
So is this to say that open source software is bad? Not at all. Its usage just requires that the enterprise architect and the systems manager understand the risks, the resources, and the timelines required to fix security problems before they result in a breach. It requires steadfast management of your technology stack. It really requires complete understanding of the software comprising the systems you run.
Innovation and Transformation
I was flipping through my social media accounts this morning and the theme of the day appears to be “innovation” and “transformation”. They were used in articles in contrast like maybe they were similar but different. I looked up the definitions of both terms in the dictionary.
Innovation (noun) – something newly introduced; such as a method or device.
Transformation (noun) – a marked change, as in appearance or character, usually for the better:
Granted, I picked the definitions but I used those that didn’t describe either term recursively. Here’s what I get: an Innovation is a new thing and a Transformation is a changed thing. So I guess they’re not really similar but they certainly are different. But they still might be related.
So what’s this got to do with Enterprise Architecture? I think it’s this…
Your future state is your innovation. You aim to create something new. Most enterprise architects are satisfied with this and set out to build this new thing.
Unfortunately, if you have an existing business, your starting point is not your blank canvass or empty project file. You need to start with where you are now. That’s your current state. The plan that gets you from your starting point to your end point or from the current state to the future state is that which generates that marked change. It’s a transformation.
You must completely understand your current state in order to build that transformational plan. That’s business-driven enterprise architecture. That’s complete understanding.
Redefining the Factory
Back in December 2013, I started a series of posts that describe processes and how to manage them. You can read them here, here, here, here, and here. Go ahead, we’ll wait.
OK, you’re back!
I have had some time to ruminate and use this processing model. It seems to breed some confusion in my business partners when I discuss it with them. The problem is my use of “Factory” to describe a core process. It is so much simpler to just call it a “Core” process. The definition, the right thing to be doing, still holds but the association is much easier to grasp.
However, we still need the Factory. The new definition of the Factory is the process flow that emerges as a transaction moves through the core processes. This is what we in systems analysis call “the happy path”. Transactions that stay in the Factory make us happy because they process in an efficient and effective manner where variability and risk are controlled.
Experience is a great teacher. I hope I never grow too old or set in my ways to change.
Enterprise Architecture Principles
I often see requests on the various forums to which I belong from someone wanting a template or list of best practices for Enterprise Architecture Principles. I am certain the requestor has visions of some check off the box model or benign fill in the blank model. He’ll want to know about patterns and stacks and stuff like that. He’ll want to know about stuff too deep in the organization to be considered “enterprise”.
I offer here my Enterprise Architectural Principles. He’ll probably be disappointed.
- Enterprise Architecture is a business discipline, not just a technical discipline. Everything is a business decision. The needs of the business drive every decision. Technology decisions must be presented as business decisions. For example, we need to upgrade the technology in this system because the current technology has known security problems. These problems are exposed on the public Internet so it’s only a matter of time before we are infiltrated if we have not been already. The cost of a security breach is at least $300 per customer record lost. We have n Customer records that could be exposed. Then there are the costs of the bad publicity and loss of customer trust, and the time we will spend defending against lawsuits. We have the following options at various price points…
- Nothing matters more than how the Enterprise Architecture supports the business. Therefore, you must understand what the business is trying to do and what needs to be done to support it. The Benefit Ratio, Benefits gained / Costs Expended, should be a really big number. Benefits are gained by the business. Costs are expended by everyone in the organization and have initial and ongoing components. These measures can be total or marginal. Benefits are generally overstated and costs are generally understated. Be brutally honest in this analysis. Make sure both sides are audited afterwards to make sure the assumptions were correct.
- If something is defined more than once, it’s not well defined. There should be only one definition for a process, one implementation of an application that supports it, and one definition for the data element that is used in it. It’s easy to maintain one set of rules. It’s really hard to keep multiple implementations of the same rule set in sync. This applies to systems and to documentation. This does not mean you can’t have multiple instances of the same implementation.
- Regardless of what your enterprise does, it can be distilled to a single set of essential processes. I call this the Factory. The Factory comprises Core processes and is supported by other processes called Safeguards and Exceptions. Core processes are the activities essential to the business’ operations. Safeguard processes are necessary to protect the Factory (e.g. Reconciliation, Audit). Exception processes allow transactions that can’t worked in the Factory to be completed or made so they can reenter the Factory. The Factory should always be improved, Safeguards should always be strengthened, and the need for Exceptions should always be reduced.
- Talent always wins over experience. And talent is expensive. The uber-talented can grasp and solve many problems in many domains. They are really expensive. There is only so much money available to hire the talent you need. You want the best talent you can get. Talent is measured by the number and depth of the skills possessed by a specific person that can be applied to the problems you have. Experience is a measure of survival. Ask any coach. Someone you find talented may merely seem experienced to a manager with different problems. You want talented people who will stay with you because they are happy and well compensated. It’s true whether we’re talking about technical people or business people. Some you can afford to hire. Some you can only afford to rent for a finite period of time. Understand the difference and spend wisely.
- Your technology stack should be as narrow as possible. OK, this seems somewhat deeper in the organization but bear with me. There are multiple business reasons for this.
- It’s easier to keep track of a smaller number of technologies than a larger number. Outdated technologies are the second largest set of attack surfaces for infiltrators. You need to understand everything running in your environment so you can monitor for vulnerabilities. You then need to patch for them. Cleaning up everything with one patch is easier than cleaning one thing with one patch and the same thing in a different technology with another.
- You need talent to manage your business and your systems. Budgets are not inexhaustible so it’s better to get great expertise and coverage for fewer processes and technologies with the talented people you can afford than to have to scrimp on expertise and coverage for many technologies because you can’t afford enough talented people. Getting a greater number of less talented people is not a good trade.
- Security is not a bolt-on. Everyone worries about the functional requirements. The business generally only wants to pay for implementing their functional requirements. At the end of the project, or worse after you’ve been infiltrated, people start to worry about security and then try to bolt it on to the existing problem process or application. Think about security at the beginning and design with those requirements in mind. The entire enterprise should understand the necessity of good security. Poor security habits by business (and technical) people are the largest infiltration attack surface. I have my own recommendation for a security mindset. Find it here.
- Technology decisions do not drive business decisions. With everything I’ve already said, you can’t make the business sub optimize in order to meet your technical needs. If their best solution requires you to expand your technology stack, you need to tell them how that increases your technical staffing needs and operating costs. This should be reflected in the Benefit/Cost ratio discussed above. If you increase operating costs enough, the benefits get diluted and maybe what was initially the second choice due to lower benefits now becomes the first choice because it has a higher Benefit Ratio due to a lower total cost of ownership.
- Templates are too specific and Frameworks are too general to be useful. The problem with templates is they are too specific to allow you to use them to define you business situation. That is unless you wrote the template because you do understand your business situation. Since each business situation is unique, it’s really hard to borrow someone else’s template to use for your situation. Frameworks are like the Pirate’s Code, they’re really just suggestions. They say you can do this…or not. How is that helpful? You could just go through the entire framework and say, “Or not” and be done with it. What you really need is a methodology.
- You don’t need an Enterprise Architecture; you need to understand the one you have. Then you need to adjust it to meet the needs of your new business realities. Too many people think that Enterprise Architecture is a new place. The problem with moving to a new place is you have to do something with your existing stuff. You either need to move it too or get rid of it. You can’t keep it where it is. It you do then you have only made your environment more complex and more expensive. Your current Benefit Ratio is your overall profit ratio or similar metric. It must be at this macro level, it’s an Enterprise Architecture. The object is to make your Benefit Ratio bigger.