SOA Optimistic Data Synchronization considered harmful

By |2009-09-04T20:58:00+00:00September 4th, 2009|Enterprise Architecture|

Let’s say that you have two systems: Adipose and BellyFat.  They both need the same information.  Adipose handles customer transactions, so it needs information about customers.  BellyFat handles the long-term management of customer information, like what products they have purchased and what rights they own.  It also needs information about customers.

How do we keep the customer information, in these two systems, in sync?  SOA offers three answers: Call-and-Response, Optimistic Data Sync and Pessimistic Data Sync.

  • Call-and-Response says: One system holds the data.  The other does not.  The system that does not hold the data calls the one that does, on a real time basis, and gets the data back quickly and efficiently.
  • Optimistic Data Sync says: Both systems keep a copy of the data.  If an event happens in either system, drop it on the bus.  The other system will get the event, interpret it correctly, and update its internal store to reflect the change.
  • Pessimistic Data Sync says: One system masters the data, but the other system keeps a local copy.  If an event happens in either system, drop it on the bus.  The other system will get the event, interpret it as best it can, and update its internal store according to its own business rules.  On a periodic basis, the ENTIRE data structure will be copied from the master to overwrite the data in the local copies (data refresh).

Each of these three has its own strengths and weaknesses.  One of them, Optimistic data sync, is so bad, however, that I’d like to call it out for special ridicule. 

Type Advantages Disadvantages
Call and Response
  • Any data entity exists once
  • Less duplication of data, lower physical storage
  • One view of the “truth”
  • Diminishes need for ETL capabilities
  • Easy understanding for software developers that are familiar with relational database design
  • Consistent inter-system data models not requireed
  • Constrains architecture – provider and consumer must be “close”
  • Requires highly available data providers
  • Cumulative negative impacts on overall ecosystem reliability
  • Requires highly scalable messaging infrastructure
  • Fosters point-to-point messaging
  • Leads to rapid increases in complexity and management cost
Optimistic Data Sync
  • Allows multiple systems to “master” a data entity
  • Diminishes need for ETL capabilities
  • Encourages loose coupling between systems
  • Supports systems that are wide distances apart. 


  • Requires highly scalable messaging infrastructure
  • Requires highly reliable messaging infrastructure
  • Assumes that data updates are always consistently applied
  • Data gradually gets out of sync, with no recourse to get it right.
  • Consistent data models are a necessity
Pessimistic Data Sync
  • Does not require expensive messaging infrastructure
  • The amount of “correctness” between systems can be carefully managed
  • Encourages loose coupling between systems
  • Consistent inter-system data models not required
  • Requires system architects to agree that one system is a master
  • Data gradually gets out of sync, but administrator can use refresh mechanism to resync
  • Requires ETL capabilities


You will choose one over the other depending on your tolerance for the “disadvantages” and your preference is for the “advantages” of any method.  However, and this is the focus of this blog post, one of these three is really not workable in the long run: Optimistic Data Synchronization.

The reason for my enmity for this approach is simple: this approach uses an underlying assumption that is poorly considered.  That assumption is that it is fairly easy for two systems to stay in sync simply by keeping each other abreast of all of the events that have occurred in either one.

The problem with this assumption is that it is NOT easy for two systems to stay in sync.  If the two systems don’t share an IDENTICAL data model, then each system has to interpret the messages from the other.  The rules of that interpretation have to be coded in each system, and that code must stay perfectly in sync.  Plus, there can be no errors in interpretation, or variations in the way that a change propagates throughout the recipient’s system.  There can be no variations in the event model between the systems.  No bugs either.  Sure…. if we can get to the point where no humans are involved in writing computer applications, then this might make sense.

Not long ago, I used to think that Optimistic data sync was a good idea, and that SOA developers should assume that their data exists outside their systems.  Heck, I used to think that call and response was a good idea too.  Both are bad in practice, with Optimistic sync being by far the worst.  There are just too many common scenarios (like one system going down for a period of time, and coming back up after missing some messages) that drives down the overall integrity of data managed in this way.

While I’d go so far as to say that Pessimistic and Call-and-Response are reasonable patterns for a SOA architect to select, the optimistic data sync method should be considered an anti-pattern, and avoided as much as humanly possible. 

Why Business Capabilities are not in the Zachman Framework

By |2009-08-13T22:29:43+00:00August 13th, 2009|Enterprise Architecture|

The Zachman framework for Enterprise Architecture is often compared to the periodic table of elements in Chemistry.  Both contain items that can be used to construct a wide array of useful things.  Both contain elements that can be understood in rows and columns with properties applied to each.  Both allow you to predict the existence of an element before one is discovered. 

Both claim comprehensiveness.  In chemistry, you cannot describe any substance made of matter without referring exclusively to the elements described in the periodic table.  In architecture, according to some enterprise architects, you cannot describe any architecture without referring exclusively to the elements described in the Zachman framework (ZF).


Unfortunately, this leads to some confusion when it comes to capability mapping.  Business capabilities are a tool used by enterprise architects and business architects to understand and model businesses. 

But here’s the rub: business capabilities do not appear in the Zachman framework.  This causes confusion among new architects first learning the Zachman framework.  The confusion goes like this: If the ZF is comprehensive, and defines everything that an architect needs, then why does an Enterprise Architect need a capability?  Are capabilities non-architectural?  Should the notion of capability mapping be disregarded by Enterprise Architects because capabilities are not part of the comprehensive Zachman framework?  Should the development of a taxonomy of capabilities be considered a pointless exercise because it isn’t architectural?


Consider this: Water (H2O) is not in the periodic table of elements.  Obvious, right?  After all, why would a molecule, like water, appear in a table of elements?  It wouldn’t, right?

But there are taxonomies, in chemistry, that include water.  There are taxonomies of molecules, taxonomies of liquids, taxonomies of solvents, etc, each of which include the molecule H2O that we know of as water.  A “molecule” is a core concept in Chemistry.

Similarly, a business capability is an architectural concept that does not exist in the Zachman framework.  It could be said to be a compound concept, just as the concept of a molecule is a composition of atoms.  A specific instance of a molecule is Water.  A specific instance of a business capability is “Lead Generation.”  In the same way that a molecule is an abstract composition of atoms, a capability is an abstract composition of roles, processes, technologies, and entities. 

So, are business capabilities part of enterprise architecture, even though they cannot be seen on the Zachman framework?  Yes.  For the same reason that molecules are part of chemistry.  A framework can define and categorize the raw materials, but it doesn’t define all the USEFUL, RELIABLE, and STABLE combinations of elements that we live with, work with, and communicate with every day.  It doesn’t even define the rules necessary to combine the elements.  (in EA, a metamodel does that).

Please don’t misunderstand.  I’m not bashing the Zachman Framework.  A taxonomy of elements is necessary, but it is not sufficient.  You can understand a lot about chemistry by using the periodic table, but you cannot do gene mapping or work in AIDS research if you limit yourself  to that single taxonomy.  You need those long (sometimes very long) taxonomies of useful, reliable, and stable combinations in order to draw conclusions about your work, organize your efforts, and find the answers you need. 

For the same reason, capability hierarchies are necessary, nay, essential to modern Enterprise Architecture.  A capability hierarchy is architectural, because it is useful to architects, used by architects, and fundamental to some architectural methods.  Is any such taxonomy perfect?  Why should it be?  In the real world, a list of things doesn’t have to be completely known, or even completely knowable, in order to be useful.

Work-back Enterprise Architecture

By |2009-07-27T22:30:12+00:00July 27th, 2009|Enterprise Architecture|

We are all familiar with the notion of a work-back schedule: a date driven schedule where we start with the end in mind, and work back to the present time, figuring out what tasks we can accomplish in that time frame.  Anything that doesn’t fit, we don’t do.  Creating a work-back schedule is an iterative process.  You describe the results at the beginning, but if you cannot deliver those results in the time you have, you figure out what you CAN deliver.

I was having a chat with another architect today who asked why we don’t do this for enterprise architecture… and I didn’t have a good response for him.  My viewpoint has often been to solve a small problem and “scale out,” (kind of EA + Agile), but his question was interesting…

Why don’t we jump ahead, four years, and describe the “Ideal” state, and then WORK BACK to today, describing what each of the steps would be to get there.  And then iterate.  If we cannot get to the “Ideal” state in four years, answer the question “What can we do in four years?” 

All too often, I’ve seen enterprise architecture described from the “Ideal” state with no respect for time.  It is as though the Ideal state is some goal hovering out in the ether, with no connection to reality.  Thus, it is easy to criticize EA as being detached from reality, because the models ARE detached from reality.

What may simply be a better approach is to describe an Ideal state based on principles and best practices, and then temper that with a work-back process, just as we would for a time-bounded project plan. 

With a work-back approach, the EA team could create multiple possible “future” states and get IT leadership to pick one, rather than having everyone buy off on an ideal state that is pretty, but unrealistic. 

Once you have an attainable “future state” model, then hide the “ideal state” in a desk drawer.  Don’t refer to it.  Use the realistic version that is actually reflective of the budget, appetite, skills, flexibility, and political realities of the IT organization.

The realistic model becomes the “future state model” that is discussed, and described, and shared, and evaluated.  It is the one you discuss because it is possible, not because it is “right” or “ideal.”  Possible trumps Right. 

Simple.  Makes sense.  Yet, in all the discussion of EA that I’ve read and walked through, including the various EA frameworks that I’ve studied, I’ve not yet seen a description of using a work-back process to describe the future state for EA models. 

What are your thoughts?   I’m interested to know.

When is the “flow” in a use case part of the system requirements?

By |2009-07-23T11:27:15+00:00July 23rd, 2009|Enterprise Architecture|

There is an odd relationship between the concepts of a use case and a requirement.  A use case is a structured chunk of text, useful for understanding and evoking requirements from the end user.  It is also a way to place those requirements into context (as in “this requirements is attached to step 3 of UC41”).  There is also the “flow” itself… the order in which information is entered and the “screens” that the user enters them into.  In many cases, a use case is quite explicit about the flow, and the customers will spend a good bit of time describing that flow.  In other cases, the flow is incidental.

So, I can see three types of “requirements” that are part and parcel of use cases:

  1. Declarative requirements attached to the use case: these “statements of requirement” may be implicit in the structure (as is the case with preconditions and post conditions), or may be attached to the use case itself. For example, if we are creating a workflow system, we may see a declarative requirement attached to a use case saying something like this: “When a user logs in to the workflow system, the default screen is the task list.”  The interesting thing is that this requirement could be attached to any of a dozen different use cases.  It is universally understandable.
  2. Implicit requirements attached to a step in the use case: these are requirements for user interaction, data fields, and functionality that are implicitly stated by the description in the use case, without being declared.  For example, if we describe a use case in a workflow system where a person can “assign” a task to someone else to perform, we could see a step like this: “Step 3: from a drop-down list, select the name of the person to whom this task will be assigned, or enter their name in the text box”.  From that, we could create some declarative requirements like “users may assign a task to another user,” “the user will be presented with a list of team members to whom it is appropriate to assign a particular task, based on the task type,” and “the user may enter the name of a person to assign the task to.”
  3. The flow of the steps in a use case:  In the use case description, the business analyst is describing a sequence of steps that the user has to go through in order to perform a specific task (or, as I like to say, complete a specific system interaction).  That sequence itself, with the implicit order of “what information is provided first” and “what information is provided next” is often created by the analyst without regard to the difficulties of asking for information in that particular order.

I specifically want to focus on type 3: implicit order.  The analyst creates this order.  In some cases, the order was created in order to “tell a story” and it is NOT a requirement from the end user… it is a requirement from the analyst.  In other words, the customer doesn’t care about the order itself.  In other cases, the customer and the analyst will carefully create that sequence of steps, focusing time and attention on the order in which information is provided.  The customer cares a great deal about the order of information (usually for valid reasons).

Here is where there is a potential for misunderstanding.  When a use case is delivered to a development team, the analyst needs to make it clear whether the order of steps is a “useful story” or a “well considered requirement.”  This indicator is missing from nearly every use case I’ve ever seen described, yet there is an interesting effect here.  Developers will read a use case and will make decisions, in code, on the basis of what they see.  Some will take all sequences in the use case as a verbatim requirement, even when it is not necessarily a requirement from the customer.  Others will look for ways to create interesting and insightful interfaces, regardless of how hard the analyst worked to create the use cases.

Testers have a problem with either option, because they are often out developing test scenarios and estimating test effort from the requirements, without consideration of the developer’s choices.

And a developer who takes the flow of a use case as a verbatim expression is the kind of developer that would never have developed the original iPhone interface, because no analyst in the world could have designed that.  The iPhone interface was developed by a design team that took the time to reconsider every aspect of user input on a touch device.  It was not dictated by a business user through a use case process.

Suggestion for improving the standard structure of use cases:

There should be an indicator of some kind attached to the use case that says one of the following options is available to the design and development teams.  Let’s call this indicator “Requirements for Flow Design” and the indicator will have one of the following values:

  • Specific – the analyst and the customer carefully considered both the order of steps and the interface controls that they want to see, and the developer should follow the flow and controls described as closely as possible.
  • Sequenced – the analyst and the customer carefully considered the sequence of information and interaction, but the customer is flexible on the interface controls that the developer may use when implementing the flow.
  • General – the analyst and customer agree with the flow, but are willing to consider any alternative flow that meets other requirements for information and functionality.
  • Suggested – the analyst created the flow as a story to elicit requirements.  As long as other requirements are met, the flow is optional.

This removes some of the guesswork about “customer intent” that is inherent in present use case design.

Very Funny – Trailer for Office 2010 – The Movie

By |2009-07-10T19:09:29+00:00July 10th, 2009|Enterprise Architecture|

Even non-geeks will get a huge kick out of this, and I’m betting that most of the folks who follow my blog will find it as funny as I did… Word up. 

My only question for the MS Marketing guys who finally loosened up enough to pay for a viral video: What Took You So Long!

Special kudos to Traffik, the agency that did the work.  Excellent Job!

Why strategy statements are necessary, but insufficient, solutions

By |2009-07-03T15:48:07+00:00July 3rd, 2009|Enterprise Architecture|

I had the opportunity recently to review an excellent article in the Harvard Business Review (HBR) on strategy development, and consider the notion of a business motivation model with respect to how a strategy is constructed. (“Can you say what your strategy is?” by David Collis and Michael Rukstad, Harvard Business Review, April 2008, link)

For those folks who are not familiar with a business motivation model, the goal of this kind of architectural artifact is to understand the different “things” that motivate an enterprise and trace the various behaviors of the enterprise that are engaged (or not engaged) to react to those things.  Things (not a technical term) refer to influencers like competitive opportunities, drivers like strategies and objectives, and business models that describe the elements of the business itself.

One thing that is clear: traceability matters.  Traceability is the ability to not only say “what” we are doing, but “why.”  It is the ability to trace our activities back to motivators that we can all agree on.

The HBR article cited above provides a clear argument for rewriting strategy statements in a different way, one in which the traceability of the strategy is described in the strategy statement itself.  For example, it would be “OK” for a ‘printer’ company to use a strategy like this: 

“Increase market penetration in the North America SOHO segment by 20% through improvements in product usability, partner marketing, and customer relationship management.”

On the other hand, according to the article, it is even better to lengthen that sentence dramatically.  An appropriate rewrite would include, in the strategy statement itself, the traceability to a key differentiator for the enterprise:

“Increase market penetration in the North America SOHO segment by 20% through improvements in product usability, partner marketing, and customer relationship management leveraging our long-term relationships with customers and deep awareness of their business needs.”

I must confess that it makes sense to care about this particular aspect of strategic traceability.  After all, creating a strategy that does not trace to a fundamental motivation around improving the health, competitiveness, and financial stability of a company would be particularly corrosive.  A bad strategy can be worse than no strategy.

The solution that the authors suggest is useful in an environment where the business does not already know who they are, and what aspects of their business are key differentiators for them.

If a business is very aware of their key differentiators, then extending the strategy statement to include them is redundant and, dare I say, mildly counterproductive.  The notion that a long-winded sentence carries sufficient weight to drive a change, outside a complete understanding of the business itself, is indicative of two possibilities: (1) an enterprise with only one business model, or (2) a business with fairly chaotic thinking.

In effect, if your business is very simple, but you don’t believe that everyone understands it, then this is good advice.  Also, if your business is in chaos, this is excellent advice.   In both cases, you need the strategy statements to communicate and provide clarity.

On the other hand, if your business is well organized but competes in a rapidly changing business environment, using a complex multi-faceted set of business models, then I have some concerns.

The limitations of sentences

Long sentences as strategy statements are a good idea, if there is no conflict between them.  In a business with one business model, this is a realistic goal.  It would be inappropriate for the leadership of the business to issue strategies that overlap or compete with one another if there is only one business model.

On the other hand, many businesses, including Microsoft and most of the rest of the Fortune 100 corporations, have many business models within the framework of their enterprise.  These different businesses will have overlapping customer bases, different products, and potentially some radically different ways to make money.  For example, as Microsoft embarks on Software Plus Services, we make money on the sale of licenses of Microsoft Exchange.  We also make money on selling access to an online version of Microsoft Exchange (Business Online Services) that many businesses find preferable to running their own e-mail infrastructure.

You can add only so much clarity to a business by stretching out the length of the strategy statements to include additional words, as the HBR article suggests.  Some things cannot be worked out using long sentences, however.  Long sentences to do not clarify overlaps, or what may appear to be competing strategies.  Long sentences do not reduce internal conflicts or clear up customer misconceptions or make it easy for the sales force to explain what your company does, especially when your company does MANY different things, for different people, in different ways.

Perhaps having longer strategy statements do work in chaotic businesses.  I’m not sure.  I believe that the problems of poor role understanding, poor organizational discipline, and poor visibility into the success factors of others are each big problems typical of a chaotic business.  If it were my call, I’d want to solve those problems before I focused on clarifying business strategy statements (although, in some sense, clarity may help).

Traceability through models

So let’s assume, for the rest of this discussion, that you can drive behavior from a strategy because your business has the organizational discipline to actually care about these statements.  Let’s assume that the problem is this: you need your strategies to be executed better. 

Now, let’s throw in a complicating factor: your enterprise has many business models… many different ways to make money.  If that is the case, then there may be effective ways that work for more people, in more ways, than the one suggested in the HBR article.

One method for building effective, aligned, and actionable strategies to model the business using a rich mechanism like the Enterprise Business Motivation Model.  This allows direct traceability between the competitive needs of the business model, the influencers that affect the business, and the drivers of change that propagate through an organization.

The method advised by the HBR article performs some of that traceability.  According to the article, some of the differentiation of the business needs to be drawn into the strategy statements themselves.  This is not bad advice.  However, the author is selecting one particular path of traceability (product differentiation to strategy) and neglecting others. 

With a model, you can draw this path, and many more.  Modeling is necessary because business strategies are simply one of the tools of change, and a full and rich motivation model, like the one described in the MSDN article, clarifies the traceability without sacrificing all of the relationships in favor of a single important one.

Having a full model doesn’t fix a chaotic business, but it is a useful first step.  On the other hand, a business without a rich and fully described motivation model will have a harder time reaching the maturity that they need in order to compete, and succeed, in the marketplace.

Once you have
developed the model, you have something very valuable.  The model lets you demonstrate how the strategies are connected to the various influencers, in the context of the (potentially many) business models of an enterprise.  It provides much of the rich context needed to prioritize business objectives and deal with competing demands for resources, time, and mindshare.  With a broad notion of traceability in place, the need to “pad” the strategy statements themselves may diminish.  More importantly, strategy statements can be shown to derive from many different paths of traceability, not just one of product differentiation.


The advice from the Harvard Business Review is good advice.  There are many situations where a set of long strategy statements is a good thing.  Companies that want to use strategy statements as an education mechanism, and not just a motivation mechanism, can use their advice to full effect.

The HBR article does not, however, take into account the many interesting kinds of traceability that may be useful to the business.  A full and rich motivation model can start where that article leaves off and go much further, allowing the business to describing its motivating factors in more than one manner (regardless of how useful that manner is). 

Should some requirements be called out as “architectural” requirements?

By |2009-06-26T10:03:40+00:00June 26th, 2009|Enterprise Architecture|

Some methodologies of software architecture, including EWITA, attempt to describe architectural processes in a manner that is quite separate from the development of software.  Is that valid?

To whit, the first step in the EWITA process is described as “architectural requirements.” Yet, there doesn’t seem to be any definition, on that site, about what criteria we’d use to decide if a requirement is architectural or not.  So if my job is to collect architectural requirements (hmmm…), then I have to ask, “what is an architectural requirement, and how is it different from some other kind of requirement?”

Consider this analogy

A few years ago, when I was considering making an addition to my home, we called an independent architect to come over and discuss details.  We talked about the functionality of the rooms, and where they would be attached to the house, and what changes we’d need to make to the rest of the house.  All of these requirements were shared with the architect, and he was planning to consider them all when creating a solution.

So are requirements architectural if the client tells them to the architect?  I don’t think that is a useful definition.

Are some requirements more inherently architectural than others?  Good question. 

Some requirements came in the form of building codes.  Were those architectural?  Surely, they affect the architecture of the building, but so do requirements about function, size, and even the ease by which we would decorate a room.

In software, the same problem occurs.  Business customers describe their use cases.  Sometimes we talk about using data from other systems. Other times, we talk about speed and performance.  Mostly we talk about functionality.  What the application will do, and how it will make their lives better. 

I don’t differentiate requirements as “architectural” vs. something else.  It is not a distinction that I find useful.  My question, fair reader, is to you: do you have a practice of attributing your software requirements with a note that says “this one is architectural?”  If so, what logic do you use to flip that attribute to “true?” 

I’m just not seeing it.

The Semantic Language of Architecture

By |2009-06-19T12:35:11+00:00June 19th, 2009|Enterprise Architecture|

For most of the last decade, we’ve seen a steady growth in the use of a simple “recommended practice” in the world of software architecture.  Well known by it’s designation, IEEE-1471 is officially titled “Recommended Practice for Architectural Description of Software-Intensive Systems.”

The standard defines words, mostly.  It answers the question: “What is Software Architecture” and does so in a simple and elegant manner using the concepts of model, view, and viewpoint.  It is also written in somewhat vague language, with the meaning of some terms being assumed and others inconsistently applied.  Creating a conceptual model from this document was no simpler than creating a model from a typical business document, even though it should have been. 

Regardless of the relatively minor deficiencies of IEEE-1471, we find it a useful way to describe software architecture and our team in Microsoft IT has fully embraced the language and concepts of this simple and elegant approach.  In addition to embracing 1471, we extended 1471 by linking in key concepts from the UML, as well as other notions like “common viewpoint types,” “architectural description methods,” and modeling languages.

A number of months ago, I created a small poster (designed to be printed in Tabloid size or larger on a color printer) that illustrates the value of this simple language.  Embedded in that poster is a conceptual model that illustrates what these terms mean in relation to one another.  I’m sharing the poster here, for others to benefit from.

My goal is to provide a simple way for all architects to illustrate, share, learn from, and talk about the language of software architecture.  I hope that this poster finds its way into classrooms and team training sessions.  Feel free to use the poster as a way to communicate and share.  I did not author these concepts.  I’m simply trying to explain them.


Note: the diagram uses some of the notational conventions of UML, but not many.  If you understand the concepts of association, composition, and aggregation in the basic class model, you can read this diagram.  The verbs on the lines between concepts are written so that a reader can read the association by following the arrow. 

If you’d like the IEEE-1471 Extended diagram, without the rest of the poster, simply click the image below.

IEEE 1471 - extended

Suggested Curriculum: MBA in Business Architecture

By |2009-06-11T13:21:00+00:00June 11th, 2009|Enterprise Architecture|

About a month back, I asked if it was time to create an MBA in Business Architecture. I’m going to follow up with a suggestion for a curriculum for such an odd degree.

The degree is provocative on its face.  After all, an MBA is first and foremost, a business degree.  Yet most Enterprise Business Architects are employees of IT departments.  How do we mix the two?

I honestly believe that the core business skills focused on in the MBA are necessary but not sufficient to be a good EA.  I believe that core technology skills are necessary but not sufficient either.  You need a mix of both.

A good EA needs to be able to operate in both spheres: business and technology.  They need to have excellent skills in both.  That is why I wonder if the program at RMIT in Australia is sufficiently business oriented.  On the other hand, the McCombs school of business in Texas has an undergraduate degree that mixes business and engineering.  That seems interesting.  There is also a university in Switzerland that has a degree in Business Engineering, but I couldn’t get many details.

The following curriculum suggestion was derived from two primary sources.  The first is the Austin Texas MBA program mentioned above.  The second is the listed curriculum of the Harvard Business School.  In a few cases, I copied the course descriptions verbatim from one of these two sites.  In most cases, I modified the course descriptions to represent the “flavor” that I would wish to see for a Business Architecture MBA. 

Basic Modeling and the visual representation of business concepts Basic understanding of models, and using modeling to recognize, represent, and improve the information, relationships and clarity of business activities.  Students are introduced to Business Process Modeling, Computer systems modeling, Conceptual modeling, and the concept of metamodels.
Financial Accounting Covers concepts and issues in the preparation and interpretation of financial statements and the use of financial information in evaluation and control of an organization.
Financial Management Examines the theory and practice of corporate finance. The focus of the course is on investment and financing decisions. Structural impacts of financial decisions are described using models.  Major topics include risk and return, valuation, asset markets and market efficiency, capital budgeting, capital structure, dividend policy, agency considerations, and derivative securities.
Business Structural Evaluation, Modeling, and Transition planning Operational Models are studied, along with transition strategies for companies moving from one operational model to another. Structural approaches to the division of responsibilities and the use of incentives and scorecards to drive organizational behavior are studied.  Students will be expected to develop a full enterprise model of an existing business or governmental institution from case studies and publically available information.
Business, Government, and Economics

This course introduces tools for studying the economic environment of business to help managers understand the implications for their companies. Students will learn the impact of: National income and balance of payment accounting, Exchange rate theory, Political regimes, and regional global integration issues.  These integration issues include: International trade, Foreign direct investment, Portfolio capital, and Global environmental issues.

Marketing Management Studies three distinct marketing issues – market analysis, developing a marketing strategy, and constructing the appropriate marketing mix for a product. The course highlights the development and visual representation of action strategies, development of products and services, establishment of effective pricing, determination of distribution intensity, and promotion of business solutions. 
Business Process Improvement / Lean / Six Sigma Examines the operational measurement view of business.  The first unit discusses statistical measurement systems for business.  The second unit focuses on business process understanding and modeling, along with methodologies for simplifying and improving business processes.   Students will be required to produce detailed BPMN models and then use Lean and Six Sigma techniques to improve them.
Strategy Development and Alignment

The objective of this course is to help students develop the skills for formulating strategy. Strategy development provides an understanding of a firm’s operating environment, competitive advantage, customer value proposition, activity configuration, and balancing the risks and opportunities available to an enterprise with the business strategy in mind.  The first module focuses on  competitive positioning; understanding comparative costs; and addressing issues such as cannibalization, network externalities, and globalization.  The second module focuses on the analytical tools of business modeling, and the alignment of business structures and behavior to strategic concerns.

Finance Based Decision Making and the Planning of IT investments Illustrates the essentials of managerial planning and control, for any business function, with a special focus on the planning and management of Information Technology investments.   This course examines topics like short-term and long-term decisions, activity based costing, strategic alignment, and benefits realization.
Negotiation, Presentation, and Influence This course focuses on the communication skills that are critical to the success of the Enterprise Business Architect, including the ability to negotiate for success, the ability to understand concerns and inform stakeholders at all levels of an organization, and the ability to influence the decision making and outcomes of teams outside your direct control.
Leadership and Corporate Accountability In this course, students learn about the complex responsibilities facing business leaders today. Using case studies that highlight difficult managerial decisions, the course examines the legal, ethical, and economic responsibilities of corporate leaders. It also teaches students about management and governance systems leaders can use to promote responsible conduct by companies and their employees, and shows how personal values can play a critical role in effective leadership.
Enterprise Architecture Models and Frameworks This course focuses on the history, evolution, and comparative study of the uses of various frameworks that target the enterprise.  This includes discussions of the Zachman framework, eTOM, TOGAF, FEAF, MODAF, and others.  The development of mature Enterprise Architecture programs, and their relationship to various business functions including Information Technology, Strategic Planning, Human Resources, and Finance are studied.
Business Architecture Patterns and Practices This course focuses on the specific terminology and practices used in the modern Business Architecture environment, including the use of heatmaps, capability maps, enterprise roadmaps, investment prioritization, IT portfolio management, Enterprise Project Management Office, and structures for corporate governance and compliance.
Electives courses
  • Business Program and Project Management
  • Information Security
  • Statistics for Decision Making
  • Software Development Processes (from Waterfall to Agile)
  • Software Operations Management and IT Service Management
  • Manager’s Introduction to Software Development
  • Software Development Languages and Environments
  • Information Modeling and aspects of Data Design

That’s my take on a potential degree program.  I know this is a bit off-topic for an Enterprise Architect, but it is good to illustrate a wish list sometimes. 

reworking my Architecture blogroll

By |2009-06-03T18:11:00+00:00June 3rd, 2009|Enterprise Architecture|

Many of the folks on my Architecture blog roll have been inactive, so I’ve dropped them.  There are other, newer blogs that may deserve attention.  If you know of a blog or wiki that covers Architectural issues, and you find it valuable, please send me the link so I can add it to my blog roll.  (Yes, you can nominate yourself).