I was reading a press release from a large health care provider notifying customers of a potential data breach. According to the company, “a test database was inadvertently left accessible via the Internet.” Upon learning of the incident, the company secured the database and removed it from public view. It then conducted an “exhaustive investigation,” determining that the database included patients’ names, addresses, telephone numbers, email addresses, medications, and “limited” clinical information.

Several companies have tried to enter the payment market and failed. When developing new disruptive innovations, success is about entering the market at the right time with the right product. Danske Bank launched a mobile payment application, which gained market dominance by following a disruptive "up market" path, from a simple application to a now-advanced payment platform, competing in several payment markets.

What strategies do you apply to modernizing a product code base? What results do you get with those strategies? This Advisor takes a retrospective look at a past project, both to describe the strategies my colleagues and I used to rearchitect the product and to validate the effectiveness of those strategies with two technical debt assessments via Cutter's Technical Debt Assessment and Valuation practice. 

Building and enterprise architecture are two aspects of the same concern: How do we see the bigger picture? How do we oversee and integrate a wide range of diverse components into a single, unified whole?

There is a price tag for innovating quickly and easily. One of the costly line items is technical debt, the increased drag on the ability to do software innovation that arises from a very specific source: failing to code with a proper level of care and diligence. Writing code is much like another procedural exercise -— writing laws and regulations. The less care one takes in the process of creating these instructions, the harder it will be to diagnose unintended problems and fix them, or even to build on the existing procedural foundations.

Gamification should not be done for the sake of gamification. It should be a business-led initiative that aligns to business strategy with a focus on improving specific key performance indicators (KPIs). The metrics to track and measure should be clearly laid down at the onset, and a business case should be created to justify the investments.

You can find variations on the definition of API all over the Internet. An API is a description of a software component in terms of its inputs, outputs, and operations. The inputs, outputs, and operations comprise the interface to the component (i.e., the application programming interface). In this sense, APIs have been part of system documentation for decades. However, there’s one key aspect to APIs that goes beyond good documentation housekeeping: APIs define interfaces and service usually without regard to implementation details.

Twenty years ago in May, the American Academy of Political and Social Science published a special issue of its periodical The Annals that focused on the challenges in risk assessment and risk management, especially within government. The premise of that highly influential issue was that assessing risk needed a new perspective; one that went beyond the methodical quantification of risk prevalent at the time to one that encompassed “the complex psychological, social,

Architecture thrives as a discipline because it holds the promise of being able to sift out the essential structural elements from the complex tangle that is the enterprise. The theory is that architecture will help us realize business value by ferreting out the essentials so that we can grapple with the elements of the enterprise that are disproportionate in their influence, and make them deliver. The promised land of architecture-enabled business value beckons tantalizingly, but are we there yet? Do we even know how to measure architectural value, let alone in financial terms?

Process modeling is organizationally challenging. Yes, there are powerful methods and tools to assist you, there are experienced consultants who will work with you, and there are sincere (and insincere) internal champions of modeling efforts. But there are also political land mines everywhere.

Cisco got serious about its IoT strategy with the completion of its acquisition of IoT platform and services provider Jasper Technologies. This development highlights just how dynamic the IoT market is. It’s also important because it essentially transforms Cisco into a major enterprise IoT provider with extensive IoT platform and packaged IoT solutions offerings.

With Goal #1, we've found an approach that helps us deal with specific challenges within the company. It's not perfect, and it certainly comes with a price. Therefore, we will continue to develop the format even further. 

The data-centric security model focuses on protecting an organization's sensitive data as opposed to protecting the overall computer networks and applications — as is the case with more traditional security models that function primarily by implementing a security perimeter designed to keep bad actors out. That said, data-centric security is intended to support an organization's overall data loss prevention strategy in conjunction with network, anti-virus, and other enterprise security incident and event management systems.

Large organizations spend millions of dollars on content management — from internal policies and procedures to customer-facing materials such as brochures and forms. Moreover, many companies still rely on printed content and physical distribution. Further still, content is often stored on shared network drives or disparate legacy systems that have evolved over time. Managing content — retrieving, changing, repurposing, approving, and publishing — becomes a time-consuming and expensive business.

Providing an enterprise-wide data store has been one aim of the enterprise data warehouse since the 1990s. One of the key lessons learned was that resolving issues of meaning and context — metadata — was central to any successful implementation. The challenges remain: very few data warehouse teams have claimed anywhere near complete success. It is also interesting to note that these issues have, finally, been recognized by data lake proponents. Tools offering big data governance, data wrangling, and similar function have begun to emerge over the last year or so. Unfortunately, once again, the tools precede an understanding of the true extent of the problem: how to traverse from data and information to knowledge and finally meaning and vice versa?

Cutter Fellow Ward Cunningham, who coined the technical debt metaphor,[1] observed that when the develop­ment process leads to new learning, re-executing the project — or parts of the project — could lead to a better result. For this reason, among others, newly developed operational software assets can contain, embody, or depend upon artifacts that, in hindsight, the developers recognize could be removed altogether, or could be replaced by more elegant, effective, or appropriate forms that can enhance maintainability and extensibility.

Technology backlash is as old as technological innovation. It is inevitable that people will grouse about new technologies and adopt them with varying degrees of acceptance. Yet, with one caveat, the cool stuff will take hold and prevail on the basis of its functionality and actual worth to people. The caveat is that this will happen only if these products do not give people some absurd reason to do a double-take and say, "What? You didn't tell me this amazing product" -- and here, take your pick -- "uses triangulation to share my location with perverts," "shares my aimless meandering around department store aisles with marketers," "leaves my television camera running," or "records my child babbling away to a beloved toy."

Agile as a concept and as a "method" is invaluable. But have you ever wondered how Agile itself was developed? Did the signatories to the Agile Manifesto use an "Agile approach" to arrive at the manifesto? The science of methods has this age-old conundrum: which method was used to develop a method? And how was that method validated? I share my thoughts with you in this Advisor.

In a recent Cutter IT Journal (CITJ) article ("Leveraging EA to Incorporate Emerging Technology Trends for Digital Transformation"), Cutter Senior Consultant and esteemed colleague Bhuvan Unhelkar and I presented our practical experience in leveraging EA to incorporate emerging technology trends for digital transformation. In the article, we shared the following steps that EA as a discipline can use in facilitating digital transformation:

IT governance defines an organization’s structure, processes, and controls used to oversee the business alignment, planning, and budgeting for the technologies the organization utilizes. The composition of the IT governance group varies greatly from organization to organization. It can depend on the type of business, the size of the organization, the complexity of the technologies used, and other factors. IT governance can range from simply the head of the IT department presenting plans and budgets to the firm’s management for approval to a mature technology committee composed of business executives, firm management, and the CIO, who together oversee and approve the approach to technology acquisition and operations.

Digital transformation continues to change the financial sector. The increasing use of smartphones and tablets has changed customers’ behaviors and fueled adoption of mobile banking. Wearables capable of storing and processing data allow us to integrate better with the technology and incorporate electronics into every domain of our lives. The question arises whether the wearables can follow that success and become a new disruption for the financial sector. And if so, will they replace or supplement the mobile devices that are currently in use?

Organizations have worried about how to protect sensitive data in big data platforms since they were first proposed for enterprise use. This is because big data environments have typically lacked the extensive security features available with the more traditional relational data warehouses that companies have become accustomed to.

In a well-functioning team, collaboration and knowledge transfer are simply byproducts of the team’s work. The fact is that embracing a business process management system (BPMS) results in a certain amount of culture shock for the uninitiated; the learning curve from a technical and business process modeling standpoint is considerable. All of these elements should be discussed at this review meeting.

As part of our shift to cloud and open source platforms, we chose to introduce a number of culture changes. Early in the process, we decided to make the cloud migration a rallying cry for the technology organization. Specifically, we challenged senior technology staff regarding the fundamentals of what our systems did and how well they served the business. This resulted in key changes in the way we addressed the fundamentals of our multi-petabyte, big data problem. In this process, new high-potential technology leaders were identified and elevated in the organization. The hiring and staffing effort that accompanied this effort also provided an opportunity to further reshape the technology profile of the company.

The architecture of the Web is elegant, and it delivers value. Is it possible to have complex, convoluted architectures that are inelegant, but that enable value? Maybe. But my intuition and experience suggest otherwise. I think that architecture needs to be as close to invisible as possible to be valuable. Architecture needs to be the invisible hand that guides the enterprise and the people within in and around it.