Where are the Architects?

Last week’s post looked at 2nd generation ERP Platforms such as Fusion from the perspective of the customer by exploring our own ‘state of readiness’ for the changes coming our way. It posed three questions: 1) Do we have the wisdom to make the right (architectural) decisions, 2) Where are the Architects? and 3) Can I.T. organizations evolve at the same pace as the technology industry? Really, it’s the second question that may be the most problematic.

It seems like Enterprise Architecture is all over the place lately. It is the topic du jour in ERP circles, and yet it has been a relatively obscure I.T. methodology since its inception as the Zachman Framework in 1987. And now, after bouts of obscurity for the past 20 years, it is a hot topic of conversation, a growing presence in large I.T. organizations and potentially a high visibility career track in itself.

But why now? Perhaps the answer lies in the very nature of the emerging 2nd generation ERP Platform. But first, let’s explore some history from ERP’s 1st generation.

In the early days of ERP, the common theme was ‘change the process, not the software.’ Hard to believe, I know, but we all had a certain degree of technical arrogance at the time. There was a period of time where vanilla software took precedence over process differentiation. ERP Platforms at the time were very rigid and thus required adherence to packaged code and workflows, i.e.: ‘vanilla’ at all cost. But business models are not rigid. For businesses to thrive, they need to 1) differentiate themselves from their competition and 2) and adapt to changing market conditions. So there was a fundamental disconnect: Rigid systems technology platforms being hardwired into flexible business models. Each necessary and yet contradictory. Conflict was inevitable.

This I.T.-Business conflict damaged many programs and led to many failed projects. But a solution evolved over time with the emergence of Business Analysts. While virtually ignored by leadership, these individuals evolved from  ‘Power Users’ during implementation projects to an ongoing role focused on ‘determining the optimal point between the business need for process uniqueness and technology’s need for commonality’. Internally, Business Analysts sit at the convergence of I.T. and Business Functions, and they play an increasingly strategic role in organizations. Externally, Business Analysts now play a key role in with technology vendors in determining the ‘Fit and Functionality’ of software. If only we had anticipated this role and nurtured it from the beginning…  

Fast forward to the 2nd generation ERP, whose very nature is defined by agility, not rigidity. Its open, service-based architectures will permit an increasing degree of flexibility in the way such platforms are deployed, maintained and upgraded. ‘Fit’ is now being defined by the degree to which the Platform matches an organization’s business model, and ‘Functionality’ is delivered by an interoperable set of applications and services, some on the ground and some in the cloud (…I know, but I had to mention cloud computing somewhere…). This technology holds great promise, but a new skill set will be required to bring it to reality.

Two imperatives emerge from this discussion:

  • Business Analysts are to First Generation ERP what Enterprise Architects will be to ERP’s 2nd Generation. The role needs to be clearly defined.
  • The Fit/Gap process step so ingrained in ERP projects must be expanded or replaced with an Enterprise Architecture process step. Packaged Software architecture did not require this. Platform Architecture most certainly does.

Next Week: The challenges and opportunities that Enterprise Architecture places on User Groups.



3 Responses to Where are the Architects?

  1. Jim Doolittle says:

    In the first paragraph where you were exploring your own ‘state of readiness’, a fourth question should have been listed. Does our organization truly understand the businees problem that needs to be solved? In today’s economic times, it is not wise to adopt an IT strategy that acquires tecnology in search of a problem.

  2. Rick Beers says:


    How right you are. So when you (or any others reading this) have a chance I’d be interested in your view as to how well Fusion is understood in business terms in the first place. In effect: what do you see as the business problems it is trying to solve?


  3. Jim Prevo says:

    Well said, Rick.

    When we did our initial PeopleSoft implementation at GMCR in 1997, the team consisted of the business experts you mention as well as IT. In a few cases we pulled people out of their jobs and created new roles (Subject Matter Experts) that were exactly the role you mention between IT and the business function. We designed the role to live in the function rather than IT. 13 years later the SME role remains one of our most important. We find ourselves needing more of them as we grow and we find that some functional managers understand their purpose better than others. This adds to the challenge significantly.

    The EAs will be even more interesting to source, fill and keep. Architects are a different breed of cat from people who become experts in what others have previously designed.

    As for clouds…I think they are easily constructed with smoke and mirrors. 🙂

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: