/Tag: Standards

Enterprise Architects should consider IT value streams

By |2016-08-07T01:06:10+00:00August 7th, 2016|Newsletter|

Businesses are increasingly looking for IT to be more efficient and to add significant value. In order to achieve this outcome enterprise architects need to consider the value streams in the organizations that add up to business value, according to one expert.

Rick Solis, the IT business architect at ExxonMobil, voiced his opinions during an Open Group conference in Austin in July. Solis has a wealth of knowledge in the area having focused on applications and technology strategy for the ‘business of IT’. His speech at the event looked at how ExxonMobil is leveraging IT4IT to grow their integrated strategic planning process. (more…)

What You Need to Know About Archimate 3.0

By |2016-08-07T01:49:14+00:00July 24th, 2016|Newsletter|

On June 14th, 2016, as part of IRM Enterprise Architecture Europe Conference held in London, The Open Group revealed its new modeling standard, known as ArchiMate 3.0. The speaker, Marc Lankhorst, the managing consultant for BiZZdesign, was joined by The Open Group’s VP of Standards and Certification Andrew Josey, as they revealed the new modeling standard amidst a warm day in the United Kingdom’s capital city.

Charging headfirst into the point, Lankhorst made very clear that the primary focus of this reveal is the two new features introduced in ArchiMate 3.0 over its previous iteration: the new strategy layer, and a new layer representing the physical world itself. Lankhorst opened with adding the obligatory list of all the overall functions of ArchiMate, which provides a universal language with concepts to describe enterprise architects. He also describes that ArchiMate 3.0 will also have visualizations for stakeholders and that this is a standard operated by The Open Group itself. Lastly, an important and welcome addition to ArchiMate 3.0 is better compatibility with TOGAF, the framework standard also developed by The Open Group, in which, as of the time of this writing, is currently in its ninth iteration. (more…)

Welcoming Archimate to Enterprise Architecture

By |2016-10-21T09:38:17+00:00June 28th, 2016|Enterprise Architecture|

I’m going to get some heat for that title… I’m sure of it.  Archimate has been a diagramming standard for some elements of Enterprise Technical Architecture for a couple of years now.  However, with the new release of Archimate 3.0, this interesting visual language is now directly useful to Enterprise Architecture from the perspective of a Vanguard EA.

(more…)

Do you perform Information Architecture or a Data Architecture?

By |2016-07-10T00:41:37+00:00November 21st, 2014|Enterprise Architecture|

So, full disclosure, I care about Wikipedia.  Call me dumb, I know.  Wikipedia has been described, alternatively, as the best platform ever invented for fostering useless arguments among ignorant people /and/ the most successful encyclopedia effort of all time.  The truth, as always, lies between these extremes.

Well, I’m part of a small team that is working to clean up the Wikipedia pages dealing with Enterprise Architecture.  One thing that we noted recently is the fact that there are two pages, similar, both rather poor, that cover essentially the same topic.

One page is called “Information Architecture” and the other is called “Data Architecture.”

(more…)

Diversity Versus Replication of Organizational Processes and Information

By |2013-10-23T16:35:00+00:00October 23rd, 2013|Enterprise Architecture|

I recently had the pleasure of joining a discussion among organizational development professionals.  During that discussion, one individual asked an interesting question: in a distributed organization with multiple operating units, spread geographically around the world, should the organizational structure of each unit be similar?

The illustration that the questioner used: organization structure (org charts).  Should the org charts look alike?

As examples, he mentioned two business units of his own company, one that was fairly “steep” with a Managing director having two direct reports, both Vice Presidents, and each of them having a small number of VPs under them.  The alternative was a different unit of the same company where the Managing director had something like 16 functional managers reporting directly to him or her.

Unit one looked something like this:

image 

Unit two looked something like this:

image

The questioner illustrated his example by pointing out in the “steep” structure (unit one), the director of Human Resources was somewhere down at level four.  In the “shallow” structure (unit two), the director of Human Resources reports directly to the managing director. 

So here’s the problem he faced: the company had a hard time moving a qualified director of Human Resources from unit two to unit one, because he would be “dropping” to four levels below the managing director, and that meant less control, less access, and less effectiveness.  On the other hand, the executive in unit two, who had a large number of direct reports, frequently complained about being overworked.

Should we force each of the units to have the same hierarchy? 

Think about it.  The company had many structures, and they were different from one another, making it difficult for a person doing work in one of those structures to translate their work, their processes, and their efforts from one to another.  This limited mobility of workers and cross-pollination of skills.  It limited information integration and consistency.  It limited process reuse.  It meant that quality of the output could be quite variable, even though each of these different units produce the same (highly complex) product!

image

 

Before I go on… what do you think?  Should the company have the same structure in every one of their geographically diverse operations? 

Would you change you mind if I told you that some of those business units were two orders of magnitude larger and more profitable than others?

Which is better: diversity or consistency (replication)?

The first observation I’d like to make about this “problem” is that it is a problem by choice, and not by accident.  The organization is NOT a franchise model.  This is a large organization that has grown over the past 100 years to be a very successful company.  Most of the life of the company preceded the information technology revolution… before computers and teleconferencing and instant communication.  Each of the business units had no choice but to operate independently.  Corporate management, early on, chose to allow each of the business units to structure itself as needed based on local conditions, people, culture, regulations, and resources.  In the terms of Jeanne Ross (author of “Enterprise Architecture As Strategy”), the organization was not a replication model.  It was a diversification model.

That said, each of these business units provided essentially the same product in each of a half-dozen different locations around the world. 

Only someone who had read Jeanne’s book would recognize that the underlying question in the room was simple.  The person posing the question saw a great many advantages to having a “replication operating model,” and didn’t see an advantage to having a “diversification operating model.”  He was seeking input on whether he was the only person who could see the advantage to making a switch.  (of course, he was not the CEO, so it was a fictional exercise, but a useful one nonetheless).

Switching from a Diversification Model to a Replication Model

There are many problems with making a switch from a diversification model to a replication model.

  1. It is fairly complex to do.  An “ideal” model must be created for all of the business units to follow.  Since none of the current business units is likely to have that “ideal” model implemented, you’d first have to create an “ideal” model and then implement it in one place to get feedback on how it actually works (if it does).  That takes time.  Once you’ve made changes in one place, rolling it out means moving people, recreating processes, and restructuring information and accountability across each of those units.  It’s essentially the same a tearing down a company and starting over.  Only each of those business units will have to keep operating while it is going on, and will have to show profit at the end of the year. 
     
  2. Loss of business unit innovation.  Companies making that kind of switch usually screw up at the “ideal model” stage because creating the “ideal” model rarely involves the right conversations with every one of the business units involved.  As a result, innovations that are working well in one area can be lost because those innovations were not copied to the “ideal” model, even if they would have been useful to everyone.  Importantly, innovations that were about to be implemented in any one unit, but had not been, are completely discarded.  Evolution of the business units themselves can be thrown backward by years.  Also, by the very fact that there is now “replication by policy,” it becomes very difficult for any further innovation to occur because it has to occur once and then be replicated everyone else, regardless of whether that innovation has the same ROI in each business unit.  (Hint: it nearly never does).
     
  3. Loss of local adaptations.  There is a notion that “the person closest to the work knows best how to do it.”  In the case illustrated above, the two business units being compared were in different parts of the world, with different business cultures and business expectations.  The PEOPLE in these organizations have a specific idea of the way that business operates.  They have relationships, cultural expectations, and accountabilities neatly arranged to suit those local conditions.  Your “ideal” structure will come from you, and you live in a business culture.  We all do.  Therefore, you have assumptions about what will and will not work.  If you impose your structure on a group of people, be prepared to re-educate every single person in every single business unit on the “one right way” to do business… and then you’d better hope that the “ideal” you have created will be more effective in a local environment than the one that was previously there.  (Hint: it probably won’t be).
     

A better way

As I have explained in my previous discussions of “Minimum Sufficient Business Integration,” I believe that many modern organizations can benefit from taking the time to find the minimum set of capabilities needed across business units to meet key corporate goals.  After that minimum set is understood, the rest of the choices can (and probably should) be left up to the people closest to their customers and suppliers.  At best, a “reference model” can be widely shared that represents your idea of what an “ideal” structure would look like… but without enforcement from above.

Of course, it can take a little thought to understand what is the “minimum” level of commonality that should be imposed.  It should be very carefully considered because, and this is important, for there to be value in this concept, that level of commonality will be strictly imposed.  No exceptions.  On the other hand, every little thing included in that “common set” will be VERY expensive to roll out consistently across a wide array of business units, so the absolute minimum set should be included.

Conclusion

My recommendation for this situation is to remain in a diversification model, but to consider moving a little closer to process and information consistency through minimum sufficient business integration (MSBI).  This means having consistency for those areas that absolutely positively must have consistency, and then to allow diversity (and innovation) to grow atop that minimum set.

In that case, the org charts would probably remain different from one another… and rightly so.

Happy architecting!

P.S.: I also want to point out that the notion of minimum sufficient integration takes place at the level of business capabilities.  Not business processes.  Not information elements.  Not business functions.  Capabilities.  So if your business architecture methods don’t use capabilities (or if you don’t know what capabilities are), you cannot use this methodology.  This post is not going to teach you what a business capability is, but I’ve blogged about them dozens of times, as have hundreds of other folks including the Business Architecture Guild and the Business Architecture Society.  Start there.

Rumination on the concept of “best practice”

By |2013-01-28T18:15:13+00:00January 28th, 2013|Enterprise Architecture|

I heard some very interesting talks today from Len Fehskens and Jeff Scott at the Open Group conference.  One thing that I picked up in a meeting yesterday was the notion that TOGAF 9.1 is built on “best practices.”  Today, as Jeff spoke about the transformation of a technical architect into a business architect, and as Len spoke about the challenges of communicating complex ideas, the notion of a “best practice” kept bothering me, and I cross-pollinated my concerns with the concepts that they were sharing.

I agree that the intent of the people who shared their practices with the Open Group was to provide practices that can be taught and followed.  I even agree that the people on the TOGAF committees that accepted the content felt that the practices represented the best that the industry had to offer at the time.  But I wonder if any of the work done in framework committees of any stripe (not to pick on the Open Group) can be held to the standard of being a “best practice.”

Are the practices in the TOGAF framework truly “best” practices?  Are these practices the best ones that the EA field has to offer? 

I guess I would have to follow the EA rabbit hole and ask “what criteria do we use to judge if a practice is the best one?”

After all, when Jeff Scott talks about business architecture using capability modeling, he believes that the practice of capability modeling is the best one to use for the results he is trying to achieve.  (I nearly always agree with Jeff, BTW.  We sometimes differ in language, but nearly never in approach).  That said, as much as Jeff and I agree, our agreement does not mean that the practice should be considered a “best” practice.  Who are we to say?  We are practitioners.  While that is good, it is not enough in my mind to qualify the practice as “best.”

To be a best practice, in my opinion, a method or approach has to meet a higher bar.  There has to be evidence that it is, in fact, better than just a “good practice.” 

I think a best practice should have:

  • Some measurement (evidence) that demonstrates that it is an effective practice, and that the measurement shows that it is at least as effective as other practices,
  • A clear understanding of the results of the practice and the context in which it is to be performed (think “Pattern Language” criteria),
  • Some analysis to show that it meets other criteria like broad applicability and simplicity, and
  • We should demonstrate the ability for that practice to be understood and performed by people who are currently in the role (e.g. can we teach it, and if we teach it, can others do it?).

 

I wonder if we went through most of our frameworks and highlighted the text that is able to meet a higher bar, like the one I describe, how much of the text would we cover?  2%?  10%? 

Is 10% coverage enough to say that a framework is based on best practices?

Aligning the EBMM with Archimate

By |2012-08-10T11:57:00+00:00August 10th, 2012|Enterprise Architecture|

I just recently had a conversation with a talented enterprise architect who had brought together the EA framework elements from numerous different sources in order to address the needs of his business.  Included in that list was the Enterprise Business Motivation Model which I developed and which I continue to maintain.

He reminded me of one of the bits of feedback that I’ve been given over the years, and that is “integrate the EBMM with other frameworks.” 

The challenge I have with that is that many other frameworks don’t have a metamodel.  The EBMM is a business architecture metamodel.  Of course, that is a quickly vanishing excuse.  The open group is largely using Archimate for their metamodel these days, and other frameworks have had metamodels from the start.  So it is time to get off my back and start taking a look at how the EBMM relates with, or differs from, standard metamodels.

I’m starting with Archimate?  Why?  Because it is at the right level of abstraction, fits well with the gaps in the EBMM (in the IT space, where Archimate excels, there is nothing in the EBMM), and allows a good relationship with tools implementation.

So over the course of the next few months, in my copious spare time, I’ll be diving in on Archimate and trying to improve my skills there, and find the ways to connect it to the EBMM.  If you have insight that you can share, please let me know.

Time-to-Release – the missing System Quality Attribute

By |2012-03-09T01:26:25+00:00March 9th, 2012|Enterprise Architecture|

I’ve been looking at different ways to implement the ATAM method these past few weeks.  Why?  Because I’m looking at different ways to evaluate software architecture and I’m a fan of the ATAM method pioneered at the Software Engineering Institute at Carnegie Mellon University.  Along the way, I’ve realized that there is a flaw that seems difficult to address. 

Different lists of criteria

The ATAM method is not a difficult thing to understand.  At it’s core, it is quite simple: create a list of “quality attributes” and sort them into order, highest to lowest, for the priority that the business wants.  Get the business stakeholders to sign off.  Then evaluate the ability of the architecture to perform according to that priority.  An architecture that places a high priority on Throughput and a low priority on Robustness may look quite different from an architecture that places a high priority on Robustness and a low priority on Throughput.

So where do we get these lists of attributes?

A couple of years ago, my colleague Gabriel Morgan posted a good article on his blog called “Implementing System Quality Attributes.”  I’ve referred to it from time to time myself, just to get remind myself of a good core set of System Quality Attributes that we could use for evaluating system-level architecture as is required by the ATAM method.  Gabriel got his list of attributes from “Software Requirements” by Karl Wiegers

Of course, there are other possible lists of attributes.  The ISO defined a set of system quality attributes in the standard ISO 25010 and ISO 25012.  They use different terms.  Instead of System Quality Attributes, there are three high level “quality models” each of which present “quality characteristics.”  For each quality characteristic, there are different quality metrics.

Both the list of attributes from Wiegers, and the list of “quality characteristics” from the ISO are missing a key point… “Time to release” (or time to market).

The missing criteria

One of the old sayings from the early days of Microsoft is: “Ship date is a feature of the product.”  The intent of this statement is fairly simple: you can only fit a certain number of features into a product in a specific period of time.  If your time is shorter, the number of features is shorter. 

I’d like to suggest that the need to ship your software on a schedule may be more important than some of the quality attributes as well.  In other words, “time-to-release” needs to be on the list of system quality attributes, prioritized with the other attributes.

How is that quality?

I kind of expect to get flamed for making the suggestion that “time to release” should be on the list, prioritized with the likes of reliability, reusability, portability, and security.  After all, shouldn’t we measure the quality of the product independently of the date on which it ships? 

In a perfect world, perhaps.  But look at the method that ATAM proposes.  The method suggests that we should created a stack-ranked list of quality attributes and get the business to sign off.  In other words, the business has to decide whether “Flexibility” is more, or less, important than “Maintainability.”  Try explaining the difference to your business customer!  I can’t. 

However, if we create a list of attributes and put “Time to Release” on the list, we are empowering the development team in a critical way.  We are empowering them to MISS their deadlines of there is a quality attribute that is higher on the list that needs attention. 

For example: let’s say that your business wants you to implement an eCommerce solution.  In eCommerce, security is very important.  Not only can the credit card companies shut you down if you don’t meet strict PCI compliance requirements, but your reputation can be torpedoed if a hacker gets access to your customer’s credit card data and uses that information for identity theft.  Security matters.  In fact, I’d say that security matters more than “going live” does. 

So your priority may be, in this example:

  • Security,
  • Usability,
  • Time-to-Release,
  • Flexibility,
  • Reliability,
  • Scalability,
  • Performance,
  • Maintainability,
  • Testability, and
  • Interoperability.
     

This means that the business is saying something very specific: “if you cannot get security or usability right, we’d rather you delay the release than ship something that is not secure or not usable.  On the other hand, if the code is not particularly maintainable, we will ship anyway.”

Now, that’s something I can sink my teeth into.  Basically, the “Time to Release” attribute is a dividing line.  Everything above the line is critical to quality.  Everything below the line is good practice.

As an architect sitting in the “reviewer’s chair,” I cannot imagine a more important dividing line than this one.  Not only can I tell if an architecture is any good based on the criteria that rises “above” the line, but I can also argue that the business is taking an unacceptable sacrifice for any attribute that actually falls “below” the line.

So, when you are considering the different ways to stack-rank the quality attributes, consider adding the attribute of “time to release” into the list.  It may offer insight into the mind, and expectations, of your customer and improve your odds of success.

The End of Flash

By |2011-11-09T12:37:58+00:00November 9th, 2011|Enterprise Architecture|

The writing is on the wall.  Adobe has abandoned Mobile Flash in favor of HTML5.  It is just a matter of time before the Adobe Flash developers switch over to producing HTML5 instead of Flash as a matter of course.  With the move to mobile devices, the dominance of Flash on the desktop will simply not matter anymore. 

I’ve been in this profession for 31 years.  I’ve seen a long list of technologies rise up to be one of the “top technologies” in a space, only to be relegated within a few years to the dust heap.  There is always a tipping point.  Apple pushed, and now, Adobe tipped. 

It is time to add Flash to the list.

Enterprise Business Motivation Model version 3.5

By |2011-07-27T00:26:07+00:00July 27th, 2011|Enterprise Architecture|

For those of you who have been waiting for me to announce the release of the newest version of the Enterprise Business Motivation Model, I’m happy to announce that version 3.5 is available now. 

To visit a WordPress site set up to explain the model, visit http://motivationmodel.com

To visit a web site produced by the Sparx modeling tool, allowing direct navigation of the model itself, visit http://motivationmodel.com/ebmm

To download a PDF document exported by the modeling tool (for those folks who love PDF files), visit this link here

Special Thanks

The Enterprise Business Motivation Model has gone through a long list of changes since the original article was published over two years ago.  I’ve spent considerable time working through the model and getting feedback from colleagues from around the world. 

I’d like to give special thanks to Michael Davison, JD Beckingham, Neil McWhorter, Bruce McNaughton, Henk Harms, Bill Ulrich, Jim Rhyne, Kirk Rheinlander, Leo de Sousa, Yelena Edelstein, Al Newman, Amy Nguyen, David Vugteveen, and many others who have commented, criticized, and asked for clarifications.  Without your concerns and your insight, the EBMM would not move forward.  Thank you!

Changes to look for

There are many changes since the last public version (v1). 

  • The business model description was updated to reflect connections between customer types and partner types, and to more completely cover the model elements of Alexander Osterwalder’s Business Model Generation. (model, description)
  • Porter’s Five Forces was added as a separate area clarifying the linkage between a Five-Forces analysis and business models themselves.
  • The dual notion of Business Capability and Business Unit Capability proved too confusing and arbitrary for a core conceptual model.  The single concept of Business capability remains.
  • The concept of Data object is now elevated to a top-level element in the model with necessary changes to the high level view. 
  • Business role was added with relationships to business processes and data objects.
  • The concepts of Regulations, Legislative Edicts and Charter Legislation were added to clarify the role of these key concepts to Government and Semi-private organizations.
  • The concept of “capability maturity” was expanded to “assessment metric” to allow a broader understanding of how measures can be applied to business capabilities in order to motivate and measure the success of initiatives.
  • Clear distinctions are made between an enterprise, a company, and a business. 
  • An additional relation has been added to business unit: relates to.  This allows models of the enterprise to include interrelationships between business units other than the normal hierarchical relationships that the existing “includes” relation allows.  This should enable a wider array of analysis models to be created for those architects who need to model a subset of the enterprise.
  • A page was created on the WordPress site to discuss the difference between a Process and a Capability.  (link)

 

Of course, we are not done.  I am publishing version 3.5 in order to insure that my conversations with other Business Architects has a current footing.  The following concerns have been shared and are under consideration for future versions:

  1. Add the ability to attach a Value Chain Analysis
  2. Add the ability to represent the accountabilities of a team in relation to the business processes themselves
  3. <<your suggestion here>>

 

As always, I welcome feedback and input.  I’m proud of where the EBMM has come so far and look forward to working with exceptional people to discuss and describe future changes to the model. 

Note: I didn’t keep a careful list of the folks who offered valuable feedback on the model.  If you offered feedback, and I didn’t mention you above, please accept my apologies and send me a note.  I’ll update this post.