This Executive Update provides a brief history of enterprise architecture to show its evolution and to highlight its key contributions over the past 40 years — from the first discussion of the term around 1975 to its 40th anniversary in 2015.

A large percentage of businesses are looking for ways to stretch their operations budgets while their user bases grow. Containerization helps with this in a number of ways.

I wonder what Marx would have observed regarding the history of IT projects in California. Last month, Elaine Howle, the state's auditor, released yet another report detailing California's continuing IT project management misadventures.

Software professionals have a hate-hate relationship with requirements. They hate that requirements have been an unsatisfactory guide to action, and they hate that they still depend on them. Agile resolved part of this dilemma, replacing the traditional requirements tome with user stories. Over time, the Agile requirements toolkit expanded to include epics, themes, storyboards, wireframes, story maps, and other types of content.

Offshoring can be a dirty word to some, but I much prefer our connected globe and the access to great skills at low cost. But this Executive Update isn't about the politics of offshoring; it's about the tricks and traps. Offshoring sensibly can have great results, be quick (with good follow-the-sun practices), and cost a fraction of what it might cost onshore. It isn't easy, however, and it isn't for the impatient.

Enterprises need architecture because of complexity; an architecture explicates the essence of an enterprise's capabilities and qualities. We can consider an architect to be an enterprise of sorts, too -- an enterprise, with some specific qualities. Just as architecture quality attributes make a system effective, so does an architect's qualities make the individual who acts in that role successful.

This Executive Report covers the benefits, considerations, and key steps involved in developing IoT-connected products and services, including connected device development, connectivity issues, sensors, supporting infrastructure, cloud-based IoT platforms, data storage and analysis requirements, and security and privacy.

This Executive Report covers the benefits, considerations, and key steps involved in developing IoT-connected products and services, including connected device development, connectivity issues, sensors, supporting infrastructure, cloud-based IoT platforms, data storage and analysis requirements, and security and privacy.

Read the Executive Report

Read the Executive Report

Although very new, the predictive API (or PAPI) concept is important. With PAPIs, we see the direct availability of machine language analysis to create predictions in a manner that can easily be integrated with other APIs. This can be employed to create sophisticated mashups with predictive capability for use in decision making. It is linkage to decision making and the ability instantly to invoke machine language prediction from diverse realms that makes PAPI important. While relatively few examples exist today, the development of the API economy and the further progress of big data will ensure that many more PAPIs are developed in more diverse areas.

Although very new, the predictive API (or PAPI) concept is important. With PAPIs, we see the direct availability of machine language analysis to create predictions in a manner that can easily be integrated with other APIs. This can be employed to create sophisticated mashups with predictive capability for use in decision making. It is linkage to decision making and the ability instantly to invoke machine language prediction from diverse realms that makes PAPI important. While relatively few examples exist today, the development of the API economy and the further progress of big data will ensure that many more PAPIs are developed in more diverse areas.

This morning we happened to notice an announcement of a project portfolio management (PPM) conference for this summer. And Cutter's Summit in Boston features a Wednesday morning (6 May) roundtable on PPM.

This morning we happened to notice an announcement of a project portfolio management (PPM) conference for this summer. And Cutter's Summit in Boston features a Wednesday morning (6 May) roundtable on PPM.

We concluded Part III of our series "One Size Does Not Fit All" discussing horizontal flow in vertically siloed organizations (see Figure 1). In such organizations, both the flow of data and the flow of decisions across the silos might not be fast enough to satisfy the needs of the enterprise. The project teams may well be frustrated with the speed of the decisions that impedes their ability to deliver. An overly burdensome approval process leaves them powerless to improve.

Because of the importance of documentation, just like a building architect would do for a construction project, EA has a vital role to play in ensuring that organizations carefully plan and execute transformation initiatives against a blueprint with a current and target state.

Teams composed of business and technology professionals should identify problems and opportunities together. The era of top-down autocratic control is over. Teams with deep knowledge of technology and business models and processes should perform the tasks listed in this Advisor to generate credibility and trust.

Teams composed of business and technology professionals should identify problems and opportunities together. The era of top-down autocratic control is over. Teams with deep knowledge of technology and business models and processes should perform the tasks listed in this Advisor to generate credibility and trust.

This Executive Update centers on continuous delivery in contrast to all of DevOps, as it is much more well defined and a process upon which IT management practices have a direct and observable impact. We should, however, view continuous delivery as an element of DevOps adoption that is focused on the flow of work from development into production. Hence, these two terms are used interchangeably within this Update.

This Executive Update completes a review of mobile offerings by the major enterprise applications players and makes some general observations about the barriers to adoption.

I suggest when teams start off, they go with shorter iterations, and once they feel they've got the Agile process down, and they're working together well, and they've got a good mindset shift, then they can expand to two or three weeks. Anything bigger than that and you're shortchanging yourself on your learning cycles.

There can be no illusions that the transition to Agile won't impact the organization. There will be effects on the organizational structure, hiring practices, funding/budgeting approaches, HR reviews, and more, if the transition is to be successful. Fortunately, our authors in this issue have encountered both the problems I've listed and the solutions to them. They provide practical advice from real-world situations to manage the difficulties you will encounter.

We use the term "cargo cults" to describe teams whose activities look and feel Agile to the casual observer, and have some of the trappings (e.g., daily stand-ups, periodic planning), but are not supported by a corresponding adherence to Agile principles. Often these teams are simply carrying on as they always did but using the camouflage of Agile terminology to mask the lack of change.