I just bought an Apple MacBook Air. As a Windows power user, I worried some about transitioning from my Windows environment to this newfangled, alien-looking device. Happily, it has been a no-brainer. Although I haven't figured out everything, I've embraced the Mac environment relatively easily, despite the fact that Microsoft has entwined itself in my DNA over the past two decades. I'm very happy with my new friend.
Finding the right MacBook case, however, is a different story. I don't know if I want a neoprene zipper bag or an over-the-shoulder messenger bag or the case that disguises your MacBook as a hardback book to confuse potential thieves. It must be light, and it must be fabulous. After hitting more than ten sites with many options but no way to filter for my needs, I think I'll make my own.
[Forrester Principal Analyst Alexander Peters, PhD. and I collaborated on this research.]
You may have heard the term "business architect" in your travels; if you haven't, you soon will. A significant number of our clients are searching for these new leaders. Broadly, BAs are responsible for developing and managing an organization's business model and business technology (BT) agenda. The business architect fills the gap between business management and IT management. One way to bridge the gap is to make it someone's responsibility to do so.
In our research, we spoke to individuals occupying this crucial role in a large European agency, a large financial services firm, a regional healthcare provider, a diversified energy provider, and a logistics firm. The need for BAs is most acute in organizations that are in the midst of transforming their businesses and information systems.
The need for business architects is manifest, but what's less apparent to these firms is how this role should be structured, who should occupy it, and what a BA's responsibilities should be (as illustrated by wide variations in job ads for the position). In our research, we found two established models for the BA role:
Leaving Scrum, Sarbanes-Oxley, and related concerns aside for the moment, a hot topic these days in app dev circles is product-oriented development. While teams in IT departments might have different motives than ISVs, systems engineers, or people in other situations, they're all interested in roughly the same thing. What it takes to qualify as a product may not be altogether clear, and there may be no definitive way of measuring whether your team's thinking and behaviors have shifted from project-centric to product-centric. As rough-hewn as the concept of product-oriented development might be, it's still an attractive destination for people coming at it from multiple directions. (Not coincidentally, this is the topic of a soon-to-be-published doc.)
In an unexpected way, many of the app dev teams that have been most successful at dealing with compliance are, as it turns out, acolytes of the product-oriented approach. They may not realize it, as their work output may not be any more productized than it was before. Instead, compliance is what turns into a product.