Emotion recognition platforms are now available that use neural networks and other machine learning algorithms to analyze and measure the facial expressions of subjects appearing in photos and video in order to determine their emotional state. Such analysis may take place on large collections of photo and video files residing in databases. It can also be performed in near real-time on images captured live — for example, for security scenarios or in-store retail applications involving shopper response measurement.

A digital transformation isn't just launching a brand on social media, hosting an electronic storefront, or connecting the enterprise workforce. Nor is it activating big data or analytics to synthesize new differentiators. A digital transformation requires escape from the routine mindset of business strategy to discover adjacent opportunities and strategies that create an asymmetric competitive advantage (i.e., a powerful advantage that denies competitors the use of similar strategies and tactics).

There has been a long-standing debate on what is the right ratio of developers to QA (dev-QA) on software engineering teams. Many managers face this debate on a regular basis. Some people argue that you need to keep a 1-to-1 ratio of dev-QA, whereas others say that you need no QA people on The Team and that developers should be responsible for the code they write.

If not managed well, technical debt can lead to major challenges for organizations resulting in increased development and maintenance costs and reduced business agility, hindering innovations in the organization. With the speed at which digital technology is exploiting the markets and its pressing need for adoption, technical debt is adding even more challenges to organizations.

Although certainly not a complete replacement for the highly customized applications that have characterized most enterprise IoT implementations to date, domain-specific IoT and industry-specific solutions offer end-user organizations a (relatively) less painful way of putting their IoT plans and initiatives into production.

Part II of this series described the conceptual, IDEAL architecture required for a modern, all-inclusive information management environment. I proposed that such an architecture provides the blueprint for a data lake, which should be considered from the point of view of the three “thinking spaces”: information, process, and people. The architectural principles are encapsulated in the acronymic name: integrated, distributed, emergent, adaptive, and latent. Latent, or hidden, implies that these three thinking spaces are not a representation of how this architecture will be built. That it is the role of a logical architecture.

This article explores some of the circumstances that have led to rampant technical debt and offers some suggestions on how they might be averted. 

Over the past few years, the professional prestige of IT departments has declined while the use of IT keeps growing. Soon, practically all smartphones and smart TVs worldwide will connect to the Internet, and while billions of these devices and the systems that power them will go online and increase the demand for IT, my professional practice and the data from the MMVM project indicate that the influence of CIOs and IT teams is decreasing, while the frustration of organizations and clients with the IT organization is increasing. The high failure rate of IT projects persists, while obsolete systems and cybersecurity risks are on the rise. That’s why it’s indispensable to start moving IT management in a different direction — the professional and deliberate management of trust, along with continuous growth in the soft management capabilities of IT professionals that have become the new core competences of the technical professional.

Architectural representations often depict not the things and people in the real world, but rather the inferred characteristics and properties of those, so the representations themselves are one step removed from things and people.

One of the forces that holds enterprise architecture (EA) back from successful management of rapid change is a perspective from earlier days of the profession. A long-standing school of thought holds that architectural work at the enterprise level is best accomplished by a formal and comprehensive architectural project, which may — one hopes — be revisited periodically. However, the practice of pure “architecture projects” is antithetical to the current rapid pace of disruptive change. Architecture work measured in months and years is a relic of bygone times. What our current situation really needs is for EA to be performed by a continuous and situationally nimble process.

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?