Enterprise Architecture - What does it mean?

My comments will be brief, as I am still behind and writing from my wife’s hospital room… but I do want to try and get back to writing something, as so much is going on.

 I recently spoke at the IIR EAC conference in Orlando. My topic seem well received, but what I found more interesting was the conversations with others about “What is EA?” Some said it was “technical strategy.” While others said “it was the merging of business and technology.” While there is merit in the first, I believe the second better describes the role of EA.

It seems to me that too many in the EA field acting as EA’s are really Solutions Architects. Not that any role is more or less valuable than any other; but, they are different and the distinctions must be explored and understood. While the Solutions Architect is focused on how to bring about a solution, the Enterprise Architect is concerned with the portfolio of solutions - and defining the portfolio of solutions requires an understanding of all things business and technology. It is the convergence of vision - both what capabilities the organization needs to meet business vision and what functionality and products are needed to deliver those capabilities.

Moreover, what is most important for the EA is to provide consulting to the business on what things might be possible given the broad range of needs, as well as, to break down the business to technology and technology to business communication gap. Not that the SA role is not also using these skills, and providing an important role. But, the EA must loosen the reins on technology and move into more broad technology concepts. For example, the EA must look beyond Oracle or SQL Server, and instead talk in terms of relational data solutions and object oriented data solutions.

Some might consider this nit picking or not even see the distinction. Again, I would go so far as to say those who do not understand the differences are most likely the ones who have less time working with the business and more time working with technology. Or to put it differently, those who have a hard time seeing the difference are probably more comfortable with technology and the more concrete role that goes with it.

 Those who do understand the difference, are most likely those who have spent time talking with sales and marketing and have heard them complain about how “IT just doesn’t hear me!” In fact, if you’ve never been close enough to business customers to understand their sometimes subtle vocabulary differences, you’re not really ready to call yourself an Enterprise Architect. And on the other side of the coin, if you are having trouble talking to some of your more technical cohorts in systems or infrastructure engineering, you might well be on the way to a successful career in Enterprise Architecture :-) 

At some point, you need to make a decision. We all do. In what way will I grow my skills? We have only limited ability, especially if we desire balance in life, so we must, for example, either decide to go deep into IdM or choose to understand what IdM is and why it is needed. And, if the later is your decision, let someone else do the product selection… with EA guidance based on the overall vision and roadmap for the business.

As always, I look forward to your input!
Patrick

Cogents for modeling enterprise architecture…

I have not been writing for a while, because I have been contending with my wife’s illness. Thinking about the affect her unfortunate situation has had on my job, our family and our lives brings to mind an important lesson for EA.

As an Enterprise Architect, it is our job to help account for forces that impact architecture. We are tasked with looking across the landscape to determine the best road ahead. In so doing, we must be sure to take into account what I call “Cogents.”  

The word Cogent is an adjective defined by Merriam Webster as having power to compel or constrain. Cogent typically refers to the validity of an argument, so it is fitting to consider it as a term for architectural planning.

In our context, Cogents is a noun I’ve created to mean factors that have the power to compel or constrain your architecture decisions. Furthermore, Cogents is plural, because we should never consider just a single force, but the collective forces. These forces I further classify as either “drivers” or “constraints.”

Drivers can be thought of as things that move one towards a certain path.

Drivers can be things like business objectives and requirements. They can also include environmental issues. Environmental here means things outside the scope of the business, such as changes in a vendor’s product strategy or new technology trends.

Constraints can be thought of as limiting one from taking a path.

Constraints are typically restricting, and include things like budget and resource limits. Like drivers, however, constraints should include both internal and external Cogents on the decision process.

Timing is key when considering Cogents…

What is equally important to identifying Cogents is the timeframe for Cogents. When a factor will impact the process is significant in determining the strategic path. For example, if you consider logistics planning for UPS, they will certainly plan their routes to deliver morning packages first, then same day, then anytime. Likewise, when planning a strategic architecture, it is important to look at all the Cogents and when those Cogents are of concern to the decision process.

The resulting decision process when considering all Cogents is similar to the critical path in project planning or logistics. With Cogents in the picture, the planning process is no longer a snapshot in time, but  instead a true roadmap for where you are going and when you will need to take each turn along the way, and most importantly, why the architecture is sound.

As we make architecture decisions, we never know all the forces that will come along to impact our plans, just as we can’t predict the unforeseen events in our lives that will create havoc on our schedules. However, if we do a good job of recording Cogents, those things that we can think of, we will be much better prepared to address the little, unforeseen bumps in the road along the way.

Patrick

What is TOGAF really?

When considering TOGAF (The Open Group Architecture Framework), it is important to start with the underlying premise behind the creation of the recommended architecture framework.

The primary vision of The Open Group is Boundaryless Information Flow. From the idea of an open exchange of information comes the idea for open systems, which results in the need for an architecture methodology that supports the future direction of technology.

So how does the idea of open exchange translate into a standardized architecture methodology? And how does a set of standardized models support the future of technology and architecture?

In order for there to be an open exchange of information and the ability to share open systems, The Open Group recognized the need for a common taxonomy and common way of viewing technology and systems. Moreover, in creating this commonality, it was recognized that the only way to help ensure architects ended up in the same place was to create a common process with enough structure to bring organizing consistency. In other words, instead of providing just the common end state to where architects needed to arrive, they also evolved over more than 10 years a methodology that would ensure some level of consistency when arriving at the end product.

So what does that mean for those considering TOGAF?

This means that TOGAF is not just another architecture methodology that may provide some structure to your EA efforts, but instead, while it may provide structure, it is really designed to provide structure towards the end of the new model of technology. Considering and adopting TOGAF is a positive move towards an architecture practice that can support such technologies as SOA and software as a service. The move is both towards internal solutions, as well as, the ability to leverage new solutions provided by industry vendors, most of whom are members of The Open Group.

So really, the idea of a standardized methodology for architecture can be considered a byproduct of the desire to move towards open computing and information exchange in the technology industry. However, at the same time, an organizing methodology for open systems would only be complete if it addressed architecture as a whole. Hence, TOGAF is truly an interrelated and complimentary framework that can not only provide guidance for the enterprise architecture practice, but also provide the guidance to assist in moving an enterprise architecture practice in the right direction towards building and leveraging open solutions.

Patrick

Timebox your EA efforts…

I recently presented a webinar on Enterprise Architecture for MEGA International. One of the topics discussed was MEGA and timeboxing the efforts of building a successful EA practice and system. A participant asked some good questions that I will respond to here.

“I am undertaking a similar process… to do a complete (this is where the issue is) analysis of its inventory of 800+ applications and though time box is a great idea, what you can accomplish meaningful during that time is the key.”

The quick answer is quite a bit; however, you’re probably looking for more details. In my experience, putting projects into a timebox is an excellent approach that applies whether you’re building a large application or trying to model a few applications. The reason for the timebox is the spiral feedback process. I see it as a method to ensure you’re efforts are not going too far down the wrong path.

In the case of what you can get done with 800+ applications in a short time using MEGA, it’s about the priorities. One of the first priorities I believe is getting an inventory of what exists. Often times, there’s not even an understanding of the landscape or scope of the architecture effort. Once the applications are identified and recorded in your system, you are officially one step ahead of where you were. This may sound like a trivial accomplishment, but you can’t really do anything effectively until it’s done.

I’ll use this as a lead in to the second part of your question -

“I am very interested in knowing what information/attributes you collected during the initial phases and was that good enough info for your team to run some analysis reports.”

So as you build an inventory, what do you initially capture? In my opinion, less is more.

You might look at the effort and think that since you are going through the exercise, go ahead and capture everything that needs to be captured. However, how many of those 800+ applications do you really need to know all the details about? For example, how many applications do you need to know the required memory size?

In my experience, the minimum information in the first round of collection should include:

• Name
• Description
• SME – Subject Matter Expert for the application so they can be contacted later for more details if needed
• Criticality – How critical is the application to the operations – 1 “without it we can’t operate” to 5 “no one would miss it”
• Type – is the application a custom built application, purchased application, customized, etc.
• Delivery – What is the delivery for the application – web, client server, workstation, etc.
• User community – How many users in total, and how many at any one time?

Beyond the seven listed, are the nice to haves, but they are not mandatory:

• Vendor – if a purchased application or custom developed by a consulting firm, it would be nice to know the vendor for reference materials
• Availability – during what times does the application need to be available
• Strategic advantage – does the application provide your organization a strategic advantage. Or, what type of strategic advantage does the application provide.

Now this is just the application and application fields. There is also organizational information – org units in MEGA – infrastructure information – servers, networks, devices – products – a customization we made to identify things like SQL Server or Oracle – services, components, business processes, etc. The list goes on.

With regards to these other items, I think the organization structure is key for the first round, and which functions of the organization use which applications is valuable in your initial assessment. Also, while it’s most likely too much effort to indentify all the infrastructure details for each application, if you can identify at which sites the application is located/hosted, that can be very useful in strategizing your next iteration. Which servers host applications is nice to know, but capturing servers for each application is most likely too much effort for the first round.

As far as analysis, knowing what you have is the best analysis to start with. Outputs like, “we have 812 applications” are extremely useful, since no one has probably ever been able to say that with confidence. Another is “20% are critical to the operation,” as well as, “80% are web based,” which will both help you set the stage for the next round of efforts. Also, once you have an understanding of the applications and some key information about them, you are now much better prepared to identify what other types of information are key to your landscape, not to mention on which applications to focus your efforts.

Because each situation is different, the timebox approach allows for iterating through and consciously making adjustments to make the most of your efforts. Also, putting a timebox around efforts does not mean you renew the project every two or three months. Instead, the project can be a twelve month engagement, but every ten weeks you are going to stop and assess what you’ve been able to accomplish and make adjustments going into the next iteration.

Finally, the timebox allows the customer to know that in a short time, they are going to see some fruits of their expenditures. To put it another way, it’s a lot easier to tell your customer you’ll have results for them in a little more than two months, than it is to say you’ll know after a year.

Patrick

Ooops!

Looks like my efforts to make the blog more user friendly were a step in the wrong direction. Hopefully I have made the necessary corrections.

 Thanks for your patience and input!

Patrick

TOGAF… What’s all the fuss?!

While attending The Open Group conference in San Francisco last month, I spoke to quite a few people who wanted to know more about TOGAF. What is it? How do I use it? How do we implement it?

I spoke with others who had obtained certification, but were still struggling at implementing the concepts in their organization. Some were certified and still couldn’t clearly explain TOGAF.

 It’s not surprising when you consider TOGAF is a large body of work that’s taken years to evolve and doesn’t prescribe how to implement the ideas in any organization.

 With an understanding of TOGAF and success at leveraging the ideas, I will share my thoughts on how you might make the most of what TOGAF has to offer.

Patrick 

The role of governance

Governance is key to establishing, and more importantly, maintaining an effective EA program.

Architecture governance provides for ensuring that products and solutions are in line with strategy. A good governance program should provide for:

• Reviewing and approving products and policies for standards
• Reviewing projects to ensure they are using approved products and following policy

At the same time, governance should provide a vehicle for keeping EA aware of new business objectives so standards can be updated, as well as providing a feedback loop to IT and business about standards and direction.

These are just some of the topics to be discussed in this section.

 Patrick

MEGA

MEGA is my preferred EA software tool and the one I will discuss. If you use another tool, hopefully you can still gain insights into leveraging your tool of choice. If you find it hard to apply the concepts discussed to your tool, I might suggest giving MEGA a call :-)  (no I don’t get a commission).

Which comes first in EA modeling… Current State or Future State?

I recently read a presentation by Gartner that says future state should be modeled before current state. Granted, there is some merit in their assertion, however, I disagree with their justification and recommendation.

Sure it would be nice, and may seem logical, to model the future and limit current state modeling to the minimum needed to get from current to future. However, the dream state approach misses the value of understanding where you are. It also misses the realities of business.

For one thing, EA is not always seen as a necessity in tight budget times, so it’s important to continually show value. One of the best ways for an EA team to show value is to be able to give answers. With good current state models, EA will have answers when questions are asked.

Additionally, current state modeling is an excellent way to understand business as it is done today, and most importantly your customers. How many times do see people in technology talking to their customers without an understanding of what challenges their customers face? In all my years, one of the biggest most consistent mistakes I’ve seen in technology is a failure to connect with the customers. How is credibility going to be established if you can’t empathize with the customer? It’s not. They want to know you understand their pain. When they feel you understand, they will trust you to help them. Otherwise, you’re no different than the other IT fool that got them where they are in the first place.

So, Gartner’s other rational is that you need to worry only about where you’re going and then go back and only learn enough about where you are so you can plan on where you’re going. In a classroom somewhere a career student is writing a thesis on this very topic. Can you see it? “It’s quite simply a matter of depicting clearly the state to which you desire, and then limit those activities involved in addressing the current reality…” Good grief! The problem is, they are disconnected with the real world. Maybe the company you are consulting to or working for has an unlimited budget that allows you to toss aside work done to date (if you found this company, please send me a link so I can apply), but I have yet to enjoy that opportunity. Instead, it’s how can we leverage what we have as we get to where we want to go? Meaning, where you are today – like it or not – is a determinate factor in where you are going to be able to go tomorrow. Besides, isn’t that one of the goals of reuse and SOA? How we can use what we already have (which is tested and proven) in moving to tomorrow.

Don’t get me wrong, I don’t think the current state should prevent anyone from dreaming big or thinking of the “wow, I’d like to be there.” But what happens when it comes time to sell the idea to management and the customers? “Don’t worry about the millions we have in PeopleSoft, this new plan is where we need to be and it will only take a few million more to get there. And of course, you’ll need to put those change requests you have on hold for a few years while we work on this new solution.” That’s a tough sell (you could probably film that conversation and put it on YouTube for laughs).

I could go on and on, and probably will in later comments, but suffice it to say, EA needs to immediately and consistently show value for you to continue to get funding. The best way to ensure this is to build the knowledge base of where you are today, then over time model where the organization can and should go tomorrow. Yes, you can and should help them to see the light at the end of the tunnel, but you have to be there in the trenches helping them deal with the challenges of today. Then, and only then, through your efforts today, will you build the trust needed to get the support needed to make changes tomorrow.

Patrick

Welcome!

Welcome to Enterprise Architecture - From Start to Success™. I created it to provide a place to share learnings on Enterprise Architecture and related topics - TOGAF, EA Software, Process Modeling, Governance, Etc.

Growing the success of EA as a practice is beneficial to us all. It’s a changing mindset for companies, and can be very challenging. Fortunately, the rewards can far exceed the challenges. While I share what works, and what doesn’t for that matter, I hope you will be inspired to share your stories, questions and insights.

 Patrick