Forrester’s Annual ECM Panel Survey, 2015. Call for Participation — Deadline July 31, 2015

Forrester’s survey for ECM decision-makers is open, and we’re looking for your participation! Take this opportunity to provide your perspectives on the key vendors, the challenges, and the opportunities you see in this technology market. This survey is intended for ECM decision-makers or influencers in end user organizations. This is not for ECM vendors or systems integrators . . . but vendors and consultants — we would love it if you could share this survey invitation with your customers. The survey will remain open until end of day Friday, July 31, 2015.

Why is your input important? Forrester uses this data to:

  • Keep our Content Management Playbook fresh and relevant. Clients who are embarking on a new or updated content initiative rely on these interconnected reports to understand the landscape and market direction and build out the business cases, continuous improvement plans, and the org charts to succeed.
  • Track the trends and emerging use cases for ECM — for both business and transactional content services. Where are investments being made? How is cloud shaping your road map? What are the top challenges facing your programs today?
  • Educate clients and nonclients alike via research, blog posts, webinars, and industry presentations. This survey data helps us validate and verify where ECM markets are evolving and aid you in making better investment decisions.

Please take this survey if you are a practitioner inside the private or public sector and make or influence decisions around ECM and/or archiving platforms. Survey participants will be provided with the survey results summary slide deck, if desired.

Read more

Forrester’s Annual ECM Panel Survey, 2015. Call for Participation — Deadline July 31, 2015

Forrester’s survey for ECM decision-makers is open, and we’re looking for your participation! Take this opportunity to provide your perspectives on the key vendors, the challenges, and the opportunities you see in this technology market. This survey is intended for ECM decision-makers or influencers in end user organizations. This is not for ECM vendors or systems integrators . . . but vendors and consultants — we would love it if you could share this survey invitation with your customers. The survey will remain open until end of day Friday, July 31, 2015.

Why is your input important? Forrester uses this data to:

  • Keep our Content Management Playbook fresh and relevant. Clients who are embarking on a new or updated content initiative rely on these interconnected reports to understand the landscape and market direction and build out the business cases, continuous improvement plans, and the org charts to succeed.
  • Track the trends and emerging use cases for ECM — for both business and transactional content services. Where are investments being made? How is cloud shaping your road map? What are the top challenges facing your programs today?
  • Educate clients and nonclients alike via research, blog posts, webinars, and industry presentations. This survey data helps us validate and verify where ECM markets are evolving and aid you in making better investment decisions.

Please take this survey if you are a practitioner inside the private or public sector and make or influence decisions around ECM and/or archiving platforms. Survey participants will be provided with the survey results summary slide deck, if desired.

Read more

What is our Enterprise Architecture mandate?

“What is our mandate?” – I cannot count the number of times an architect (both enterprise, solution, integration and other) asked me that question. Mostly in the sense ‘can we dictate the solution?’ and then expected me to provide a clear answer. Perhaps I am slow-witted, but the question just baffles me. I mean, unless […]

Intro to EA: The Paradigm Problem

The advent of the commercial employment of computers in the 1950’s ushered in an era of dramatic productivity improvements in both the private and public sectors. Clearly, using a computer to perform the processes of the business rather than people performing the processes is better because computers do things the same way every time whereas people make mistakes, computers perform in electrical (or electronic) cycle times and people in human cycle times and computers (in most cases) are cheaper than labor. Therefore, computers are “better, faster and cheaper” than people and there is enormous incentive to get the new computer systems implemented as quickly as possible. Every moment a new automated computer system is not implemented, it is costing the Enterprise quality, time and money (better, faster and cheaper)!

Better, faster, cheaper legislates the entire focus of the Information Technology (IT) community on implementation since its inception. In fact, if you ask someone from the Information community what they do for a living, the response typically is that they build and run systems… a manufacturing (that is, an implementation) concept. In fact, no value is perceived from the investment in IT until some full time equivalents (FTE’s) are displaced by a new system saving (or making) money in the current accounting period. Very little effort has been focused on the Enterprise, that is on Enterprise Engineering, the design of the Enterprise itself.

This is entirely consistent with Fred Brooks’ observation: “The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult….  No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later. The most important function that the software builder performs for the client is the iterative extraction and refinement of the product requirements.”

Since IT has been replacing people with machines since its inception, it has literally been manufacturing the Enterprise… but the Enterprise was never “engineered.” Therefore, IT was not manufacturing the Enterprise, they were manufacturing “parts” of the Enterprise… “systems”… and the resultant “parts” (systems) don’t fit together. That is, they are not “integrated.” Fred Brooks is attributed with the observation that “programming is manufacturing, not engineering.” If someone was building Industrial Age products like airplanes, buildings, automobiles, computers, etc and they manufactured parts that didn’t fit together, what would have to be done?… Scrap and rework! There is no way to fix this problem after the fact. If you want parts to fit together, they have to be engineered to fit together before they are manufactured.

This elicits a quote Jay Forrester:

“Although social systems are more complex than physical systems, they belong to the same class of high-order, non-linear, feedback systems as do physical systems.

“People do not accept the idea that families, corporations, and governments belong to the same class of dynamic structures as do chemical refineries and autopilots for aircraft.

“Organizations built by committee and intuition perform no better than an airplane built by the same methods … as in bad airplane design, which no pilot can fly successfully, such badly designed corporations lie beyond the ability of real-life managers.

“I anticipate that future management schools devoted to ‘enterprise design’. …a fundamental difference exists between an enterprise operator and an enterprise designer. A manager runs an organization, just as a pilot runs an airplane. Success of a pilot depends on an aircraft designer who created a successful airplane … who designed the corporation that a manager runs?”

Historically, the programmer (or someone from IT) defined whatever components they want or need to get the code to run for implementation. In fact, I think this is the essence of the Agile programming community at present. No wonder we have so many different versions of the truth (data) and the plethora of “parts” (systems) that don’t fit together (are not “integrated”) in the Enterprise.

The “raw material” for doing engineering are the engineering design artifacts, the descriptive representations of the object being created. The collection of these design artifacts are its “Architecture.”

I submit, if every plumber, every carpenter, every electrician, every architect, every electrical engineer, every hydraulic engineer, every structural engineer, every general contractor, every project manager, every building code inspector, every legislator, every lathe operator, every building owner, every building occupant defined Building Architecture the way only they wanted to define it, we would not have hundred story buildings … we probably wouldn’t have even 3 or 4 story buildings! (The same exists for airplanes, automobiles, computers, ocean liners, etc., etc.) To build complex objects that have any reliability, longevity, maintainability, quality, etc. the parts all have to be engineered such that they fit together (are integrated) into the whole of the object.

Is that important?

In the Public Sector, when publicly used complex objects fail … automobiles crash, buildings fall down, airplanes crash, drugs harm people, etc. that is, when citizens get hurt, the government intervenes with regulatory action. “Before we allow you to build a building in downtown Los Angeles, we would like to see your Architecture.” In Los Angeles, it is the Fire Department that does the “Plan Checks” … they have to put out the fires and a plan check for a hundred story building takes several years and costs a lot of money. The Federal Aviation Administration is famous for evaluating airplanes and airplane manufacturers. The Food and Drug Administration is famous for enforcing regulations that provide for health safety of foods and medicines. Etc., etc.

By the same token, if every programmer, every database administrator, every data administrator, every systems analyst, every project manager, every IT manager, every network administrator, every business analyst, every CEO, every vice president, every CFO, every strategic planner, every Enterprise Architect insists on defining Enterprise Architecture they way only they want to define it, there is little wonder that the Enterprises of today are not integrated, not flexible, not aligned, not interoperable, not reusable and not meeting expectations!

It does not take too much imagination to speculate that if Enterprises cannot accommodate the dramatic escalation of complexity and the extreme rates of change incumbent in the Information Age environment and Enterprises fail and citizens become unemployed; that the government will intervene with regulatory action… “before we give you a license to operate in our geographic domain, we would like to see your Enterprise Architecture.” In fact we presently see the Klinger-Cohen Act, the Federal Enterprise Architecture Policy, the Department of Defense Architecture Framework Standards, etc. in the United States alone.

Is this important?

If an airplane cannot accommodate the stresses of the external environment and crashes, you might lose 3 or 4 hundred people. If a hundred story building cannot accommodate the stresses of the external environment and implodes, you might lose 3 or 4 thousand people. If a pharmaceutical drug cannot accommodate the complexity of the human physiology, you might lose 30 or 40 thousand people. If a Private Sector Enterprise cannot accommodate complexity and vagary of the changing environment you might lose 3 or 4 hundred thousand people. If a Pubic Sector Enterprise cannot accommodate the changing demands of the global population you might lose 3 or 4 million people.

Author

John A. Zachman

European Interoperability Reference Architecture

European Interoperability Reference Architecture The European Interoperability Reference Architecture (EIRA) is an architecture content metamodel defining the most salient architectural building blocks (ABBs) needed to build interoperable e-Government systems. On 8 June 2015, release 0.9.0 beta of the EIRA entered an eight-week public review period. Stakeholders working for public administrations in the field of architecture […]

Information Security in the boardroom

Sharing knowledge and good practices is one of the core values of BiZZdesign. We regularly organize and contribute to online and offline seminars, conferences and round tables. Recently there was a very successful seminar on Enterprise Risk and Security Architecture for Dutch financial institutions. After presentations on “Security is not an IT problem”, the lacking relations between policies and measures in many organization, we had a World Café on various topics. Please share your good and worst practices by reacting to this blog.

Services and disservices – 6: Assessment and actions

Services serve the needs of someone. Disservices purport to serve the needs of someone, but don’t – they either don’t work at all, or they serve someone else’s needs. Or desires. Or something of that kind, anyway. And therein lie a huge range of

Navigating the Path to Value

The business environment is changing at a much greater pace, from new payment mechanisms through to the Internet of things. Technology and customers are changing the very fabric of business, which is not only impacting new propositions, but also the way changes are prioritised. To win in the new economy leaders must look beyond cost, Read More