Todd Biske: Outside the Box

In a comment on my “EA and SOA Case Panel” entry, Surekha Durvasula asked me a couple questions. They didn’t come up in the panel discussion, so I thought I’d respond in a separate entry, as the topic should be of interest to many of my readers. She wrote:

Is “reuse” of a business service considered a valuable metric? How does governance influence the “reusability metric”? Did this come up during this SOA panel?

Specifically, I am wondering if service governance has any bearing in terms of not only promoting the usage of a service but also in ensuring that the enhancement of a service is in keeping with the enterprise-worthiness of the service. Often times it is the evolution of the service where cross-domain applicability is sacrificed.

Also, is there a trend in the industry in terms of promoting business service usage via the use of a “rewards program” or in tying it to compensation packages? Have some industries reached a level of maturity in terms of service reuse especially in those industry verticals that are hit with global competition forcing them to reduce overall operations costs and/or to offer novel product offerings?

Let’s take these one at time. On the subject of reuse, I absolutely think that number of consumers is a valuable metric. At the same time, when dealing with reuse, one must be cautious that it isn’t the only metric of interest. I’ve been in meetings with individuals that have made comments like, “If a service isn’t reused, why are you making it a service in the first place?” I strongly disagree with statements like this, as do most pundits in the SOA space. To defend this position, I frequently quote the oft-referenced Credit Suisse SOA efforts, where they stated that their average number of consumers per service was 1.5. This means that there will be many services that aren’t reused, and probably some that are used by many consumers. While reuse is important, we also have to be looking at metrics for agility, which loosely stated, is the ability to respond to business change. This will involve tracking the time it takes to develop solutions. The theory is that by breaking a solution apart into autonomous services, I reduce the number of touch points when the business needs change. In reality, it depends on the type of change. For example, most of us would agree that a separation of presentation logic from the core business processing is a good thing. That being said, there certainly are plenty of changes that will require touching both the presentation logic and the business logic. One of the most difficult parts of SOA is knowing where to draw service boundaries, because the rules are always changing.

Back to the subject- if we have reusable services, what role does governance play in ensuring that the service doesn’t fork into a bunch of one-off, consumer-specific variants? This is a very interesting question, one that I hadn’t thought much about in the past. My gut is telling me that the burden for this belongs with the service manager, not with a governance team. That’s not to say that there shouldn’t be any involvement from the governance group, but I see a much stronger role from governance in establishing the original service boundaries and assigning service ownership. For future versions, the service manager must be the one that can recognize when the service is getting outside of the boundaries that were originally intended, and this will happen. In some cases, boundaries may need to be redefined. In other cases, we may need to push back on the consumers. All of this starts with that service manager. The service manager must balance the needs of the consumer against the cost of service management. Measurements for determining that manager’s performance should include the number of versions currently being managed and the time required to respond to consumer requests. It is then in their best interests to keep the service focused on its original purpose.

Finally, regarding “rewards programs” or incentives, I don’t know that I’ve ever heard of a case study centered around reuse that didn’t involve incentives. SOA is about culture change, and it’s extremely difficult to change culture without incentives. One only need to look at a government to understand how change occurs. No one would be happy if the federal government mandated that all cars sold starting in 2008 had to get 50 mpg or higher. This is the “big stick” approach. I’ve got a big stick and you’ll get whacked with it if you don’t comply. In terms of IT incentives, one manager I worked with summed up the “big stick” approach well, “Your incentive is that you’ll keep your job.” More typically, the government takes a “carrot” approach, at least at the beginning. Tax breaks are granted to companies that produce high mpg vehicles and to consumers that buy them. These incentives may not even cover the added cost of that approach (e.g. does a $500 tax break for 4 years justify spending $3000 more on a vehicle?), but just the fact that they exist can often be enough to encourage the behavior. Only when enough momentum has gathered does the stick come out, essentially stating a policy that is what the majority of the people are doing already. Overall, I think that incentives should be viewed as a short-term tool to get momentum behind the change, but should always be planned for phase-out once the desired behavior is achieved. Have we reached that point with SOA? I’ve yet to see a company that has. Have we reached that point with reusable libraries? Partially. Most developers would not build their own low-level frameworks today. The problem, however, is that multiple frameworks exist, and there’s still strong resistance in many organizations to having a single solution coming from a frameworks team. I heard my first talk on reuse back in 1998, so it’s very clear that widespread culture change takes a long time to do.

I just saw this article on AppleInsider which stated (not surprisingly) that first year Apple TV sales are coming in far below expectations. While I am definitely an Apple fan, I don’t currently own an Apple TV. I also don’t own a HDTV, but, if I did, the key to me purchasing the device would be video rentals.

Right now, as it currently stands, Apple TV is not a good value proposition for me. First off, I’ve only purchased one video from the iTunes store, and that was because something got screwed up on the DVR and my wife wound up missing an episode of Grey’s Anatomy. I already pay enough for my satellite TV, and am not about to drop it in favor of purchasing individual shows via iTunes. On top of that, the only physical video media I’ve purchased have been kids DVDs. I have, however, rented a few movies. More often than not, this has been associated with some plane travel where I’d really just like to put it on my iPhone. I’ve never done the NetFlix thing, but I think something without a due date but with restrictions on number of times it can be viewed would work best. Trying to find 2+ hours to watch a movie with three young kids running around the house is all but impossible.

The second feature that I’d like to see would be a device that would only be a streaming video recipient that could hook up to the TV. How I really want my video to work is to have one central server that has all of my video and can then stream it to any TV in the house. I’d rather not have to have computers hooked up to each one, however. Take Apple TV, strip out the hard drive, leaving just the HDMI out and the wireless connectivity, and now it’s at least getting tempting. You could either use it in conjunction with Apple TV (if you need external storage of your video) or simply with iTunes on a Mac/PC in your house. It would be the video equivalent to AirPort Express where it connected to your stereo system.

In reality, the best scenarion would if Apple would release a real Apple TV as a competetively priced 42″ or 46″ 1080p LCD TV to the higher end competition that contained a hard drive and wireless capabilities. While I doubt they’d do it, Apple could OEM it to other manufacturers, since the integration with the display should be pretty standard at this point and not get in the way of the user experience. Add in DVR capabilities, the ability to sync recorded programs on the DVR with iTunes so I can move them to my iPod/iPhone or watch them on another computer or TV, and the ability to auto-tune my satellite receiver, and I’d be all over it. Who knows, maybe Steve will announce something close at the next MacWorld.

I’m checked out now, and in the closing session which is an open research panel with four Gartner panelists. They’re throwing up a statement and then debating it. The first prediction is “Through 2012, 40% of EA programs will be stopped due to poor execution.” The audience seemed to be in favor of the statement, although I wasn’t. Some of the audience comments had to do with lack of funding, lack of support, confusion with the value proposition for EA. I think it’s likely that 40% of the EA programs may change in how the company is attacking the problem (in fact, probably even more than that), but I’d be surprised if the program was abolished altogether.

The next statement is “By 2010, 70% of EA teams will be forced to spend as much time on information architecture as they currently spend on technical architecture.” About 70% of the audience agreed with this statement. I differ slightly. I definitely think the emphasis on information architecture will increase, but I also think some of the technical architecture may decrease. So, I would say that information architecture will probably receive equal treatment to technical architecture, but probably not as much as what technical architecture receives today. Interestingly, Nick Gall asked how many of us expect that Business Process Architecture will increase, more so than Information Architecture, in the next few years, and about 70% of us (myself included) agreed.

The final statement is “By 2010, the primary focus of technology architecture will shift from defining product standards to identifying and describing shared and repeatable technical services.” About 70% of the audience agreed with this. The key word that I disagree with on this one is the use of the term “technical services”. If your definition of this term includes “business services” exposed through technology, then I’d agree. If we’re talking about capabilities in the technical domains, like security, routing, etc., then I disagree. I think they are using the former definition, so I would agree with this one.

Time to head to the airport. I’d like to publicly thank the SOA Consortium and Pascal Winckel with Gartner for giving me the opportunity to be a speaker and for putting on two great summits. I especially enjoyed the EA Summit and hope to attend again.

This session is being presented by Tom Scholtz. His opening message is that we have to avoid one-size-fits-all security solutions and that we need to think strategically, otherwise we’ll always be behind the risk management curve. The approach he’s advocated is very consistent with EA: Plan, Build, Govern, Run, and back to Plan again.

He’s now talking about the organization model for information security in the future. The first item is that he recommends moving the corporate information security team outside of IT to increase the message that security is a corporate issue, not just an IT issue. This team would be involved with risk management, policy management, program management, business continuity management, architecture, and awareness. This group would report to a Corporate Risk Manager. Within IT, reporting to the CIO, there would be an IT Information Security Team looking at risk assessment, design and implementation, disaster recovery plan, security operations, and vulnerability assessments. Within business units, they would have local continuity plans, awareness, and policy management. Tying it all together is governance.

He’s now recommending that we become more process centric about security. In the vertical dimension, there are four key protection processes:

• Identity and Access Management
• Network Access Control
• Vulnerability Management
• Intrusion Prevention

In the horizontal dimension, he has strategic processes:

• Risk and Policy Management
• Security Architecture
• Business Continuity
• Relationship Management

Not much more to report on this one, as I need to skip out early and check out of the hotel to catch my flight home. This definitely looks to be more appropriate to an ISO manager than someone closer to the technology like me, but I’ll have to review the notes in the conference materials to get more detail.

Courtesy of Brandon Satrom, who I met here at the Gartner Summit, comes this hilarious YouTube video. If you don’t see it below, click here to go to YouTube.

[kml_flashembed movie=”http://www.youtube.com/v/I6IQ_FOCE6I” width=”425″ height=”350″ wmode=”transparent” /]

In this session, Robert Handler is giving a talk entitled Communication, Persuasion, and Interpersonal Skills for EA. In a previous job, I worked with someone who was passionate about communications. He helped us create a communication plan around SOA and our competency center, and I really think it made a huge difference in our efforts, so I had a keen interest in this topic. I’ve previously blogged on some of the subjects in this presentation, including my Focus on the consumer entry.

Robert is spending a lot of time talking about Marketing and Sales, which is a great approach for this subject. For example, one task in marketing is identifying and segmenting it. Robert correctly points out the different segments for EA (senior leaders, business unit leaders, IT leaders, and IT groups) all want different things. Great point. I’ve met many technical people who want to create one thing and expect that everyone will see the inherent value in it when there hasn’t been any effort to tailor it or present it according to the differing needs.

He’s also spoken about creating the delivery system. Are you going to use a web portal? Wikis? Think about how your EA deliverables will be sent out to your markets. He’s also addressed branding and its importance.

On the sales side, he’s begun with a discussion on stakeholder analysis, and a detailed level at that. Again, it’s about understanding how to communicate and sell to the particular personalities and how they make decisions. Do they want a lot of detail? Do they want structure? Do they want to hear more about people and social issues, or do they want specific tasks? Again, there’s no one approach, it’s about matching the right approach to the right person.

He’s now talking about persuasion, and presenting techniques from the work of Dr. Robert Cialdini. He defines persuasion loosely as getting people to reply to your requests. The principles associated with persuasion include:

• Contrast principle: You can change the way someone experiences something by giving them a contrasting experience first.
• Principle of reciprocation: people feel obligated to give back somethign similar to what was given to them.
• Principle of scarcity: People want what they can’t have.
• Principle of authority/credibility: People defer decisions to experts, legitimate or otherwise.
• Principle of trust: Admit a flaw or weakness to show you are trustworthy.
• Principle of consistency: People want consistency and to be viewed as consistent.
• Principle of liking: People like those who like them, pleasant associations is the same as liking, people say yes to those who they believe are cooperating.

Message: keep these principles in mind as you sell EA. For example, he told us about a group that had little badges with LED lights that were given to projects that worked well with EA. The EA team was very stingy with them, however, adhering to the principle of scarcity. The result was that teams worked that much harder to be compliant, because they wanted these $2 badges that they could have ordered from Oriental Trading Company.

I’ve been really impressed with both of Robert’s sessions that I’ve attended. I’ve have to look into more of his research and recommend that other Gartner clients out there do so as well.

This is the afternoon keynote in the EA Summit being given by Susan Cramm, the Founder and President of Valuedance, and CIO Magazine columnist. Some takeaways from her true story of Jerry, the Irritating Architect.

• People will choose likability over competence any day.
• Motivation is built upon respect, connectivity, and pride. She used these three concepts then in the key phases of architecture: strategize, architect, lead, govern, and communicate.
• You can’t influence people you don’t know.

Overall, it was a good presentation. It definitely delivered the message of adding value to others and enabling them, rather than the opposite extreme of taking power from others and disabling them. Elements of Jerry that she described made me think of a very good book I’ve read, “The No A******e rule.”

In this session, Robert Handler (of Gartner) is talking about the relationship between Enterprise Architecture and Project Portfolio Management (PPM). First off, there is clear overlap between the two efforts, provided that your PPM efforts are involved with the actual project definition and approval efforts, and not simply involved after project are approved and underway. Both efforts have the common desire to define projects that are intended to progress the company from a current state to a future state, although the criteria involved in project selection probably varies between the two.

On the PPM side, the biggest challenge is that this often isn’t happening. The survey quoted in the slides showed that the bulk of the time in PPM is spent mediating discussions on project priority, and just over 50% of the projects are even under the purview of the PPM effort. On the EA side, the slide states that most efforts are “mired in the creation of technical standards,” operating too much in a reactionary mode to current projects, and have very little effort on gap analysis. So, the end result is that neither effort is necessarily meeting their objectives, especially in the areas where they overlap, and neither effort is communicating well with the other.

He’s now showing an anchor model, and demonstrating how projects can be mapped onto the anchor model to show areas of concern and overlaps. I mentioned this anchor model in my blog entry on the Beginner’s Guide to Business Architecture session, and it’s jumping out again. This is definitely something that I need to get more information on, and hopefully start leveraging. He also presented a common requirements matrix and scoring approach which can assist in prioritization. The one challenge I see with this latter approach is that the projects all have to come along at the same time, which isn’t always the case. We’ll see if he gets to my question on this subject that I just submitted. (Note: he did, and pointed out that it doesn’t assume that everything comes in the same time, but that you do need to be willing to make adjustments to in-flight projects such as removing resources, altering scope, etc.)

Back to EA side of things, he’s advocating the use of patterns, principles, models, and standards as part of the architectural guidance that projects use. No arguments from me here. His slide also states that resource utilization in one organization went from 67% to over 80% when these are used effectively.

His closing recommendations are pretty straightforward. First, EA needs to be coordinated with PPM activities. Someone needs to take the first step to establish some synergies. Second, use coarse-grained EA deliverables for better project selection criteria. Third, use fine-grained EA deliverables on projects as gating factors. Fourth, capture some baselines and measure overall improvements, such as how long the design phase takes, productivity, etc. Finally, evolve maturity and effectiveness from where you are toward the ideal.

Overall, this was a very good session. It could have been a bit more prescriptive, but in terms of clearly showing the relationship between PPM and EA, it hit the mark.

In this panel discussion, a question I submitted was lucky enough to be directed to the panelists. It was whether or not they had a Business Architecture practice, and if so, was it part of the IT (or EA) organization or part of the business organization. Only one of the panelists, Buck Stuart of Great American Insurance, said that he had an actual Business Architecture practice, the other two, Randy Lakner of Sysco and Gouri Das of McGraw-Hill Education, both said they don’t have a practice per se, but are taking steps to ensure appropriate business input into EA practices, especially as it applies to SOA. All of the panelists agreed that the practice belongs within the business and not within IT. Randy pointed out that he had hired someone to be a Business Architect, but the effort didn’t succeed, not because it was coming out of IT, but rather because the business wasn’t ready for it. The panelists also indicated a strong relationship between Business Process Improvement initiatives and Business Architecture. Based upon those comments and my own thoughts, I would expect that increased adoption of BPM suites are likely to highlight the need and hopefully establish a business architecture practice in the organization.

In this talk, Richard Buchanan spoke for a long time on the tools that the business uses for strategic planning. Now, he’s talking about what EA’s need to do, because as he says, “EA is about strategic planning.” Tools he recommends includes product/service lifecycle management. Specifically, we need to model the definitive list of products or services the organization provides. This sounds a lot like Application Portfolio Management, and I would agree that not having that portfolio of IT “stuff” makes strategic planning very difficult. Another tools that he recommends is competitor analysis, which covers who the competitors are and how the organization competes with them. The next one is portfolio analysis, which is analogous to the Project Portfolio Management discussed in many of the AADI sessions. What are the major initiatives the organization is engaged in? Are there mergers and acquisitions in the pipeline?

The main takeaway from this for me is that a huge component of EA is analysis. I’ve always felt this, but given that many EA’s have grown out of the developer ranks and not the analyst ranks, myself included, we sometimes need to give ourselves a kick in the pants to do some of this work, rather than staying in our comfort zone of technology architecture and design.

While I didn’t attend the later session on it, in the opening keynote of the AADI Summit on Monday, the term “Context-Oriented Architecture” was mentioned. A colleague (thanks Craig!) caught me in the hall and asked me what my thoughts were on it, and as usual, my brain starting noodling away and the end result was me leaving the conversation saying, “you’ll see a blog entry on this very soon!”

I’ve brought up the slides from the Gartner session on it, and they estimate that sometime in the 2010’s, we will enter the “Era of Context” where important factors are presence, mobility, web 2.0 concepts, and social computing. The slides contain a new long acronym, WYNIWYG (Winnie Wig?), which stands for “What You Need is What You Get.” While it seems that the Gartner slides emphasize the importance that mobility will have in this paradigm, I’d like to bring it back into the enterprise context. While mobility is very important, there is still a huge need for WYNIWYG concepts in the desktop context. There will be no shortage of workers who still commute to the office building each day with the computer in their cube or their desktop being their primary point of interaction with the technology systems.

I think the WYNIWYG acronym captures the goal: what you need is what you get. The notion of context, however, implies that what you need changes frequently within a given day. Keith Harrison-Broninski, in his book Human Interactions, discusses how a lot of what we do is driven by the role we are playing at that point in time. If we take on multiple roles during the course of our day, shouldn’t we have context-sensitive interfaces that reflect this? If you’re asking the question, “Isn’t this the same thing as the personalization wave that went in (and out?) with web portals?” I want to make a distinction. Context-sensitivity has to be about productivity gains, not necessarily about user satisfaction gains. Allowing a user to put a “skin” on something or other look and feel tweaks may increase their overall level of satisfaction, but it may not make them any more productivity (I’m not implying that look and feel was the only thing that the personalization wave was about, but there was certainly a lot of it). As a better example of context-sensitivity, I point to the notion of Virtual Desktops. This has been around since the days of X Windows, with the most recent incarnation of it being Apple’s Spaces technology within Leopard. With this approach, I can put certain windows on “Virtual desktops” rather than have all of them clutter up a single desktop. With a keystroke, I can switch between them. So, a typical developer may have one “desktop” that has Eclipse open and maximized, and another “desktop” that has Outlook or your favorite mail client of choice, etc. Putting them all in one creates clutter, and the potential for interruptions and productivity losses when I need to shift (i.e. context-shift) from coding to responding to email.

Taking this beyond the developer, I bring in the advent of BPM and Workflow technologies. I’ve blogged previously on how I think this will create a need for very lightweight, specific-purpose user interfaces. Going a step further, these entry points should all be context-sensitivie. I’m doing this particular task, because I’m currently playing this role. Therefore, somehow, I need to have an association between a task and a role, and the task manager on my desktop needs to be able to interact with the user interaction container (not any one specific user interface, but rather a collection of interfaces) in a context-sensitive manner to present what I need. In our discussion, he brought up an example of an employee directory. An employee directory itself probably doesn’t need to be context aware. What does need to be context-aware is the presence or lack thereof of the employee directory depending on the role I’m currently playing. Therefore, it’s the UI container that must be context-sensitive.

All in all, this was a very interesting discussion. In looking at the Gartner slides, I definitely agree that this is a 2010+ sort of thing, but if you’re in a position to jump out (way) ahead of the curve, there’s probably some good productivity gains waiting to be had. I recommend getting pretty comfortable with your utilization of BPM technology first, and then moving on to this “era of context.”

I’m now in the Beginner’s Guide to Business Architecture session from Philip Allega. So far so good. He’s got a slide up right now showing an Anchor Model which presents a view that aligns nicely with my mental model of a diagram that shows the horizontal and vertical domains of the business. It’s nice to see something more formal than my own thoughts, and is exactly what I’m hoping to learn in this session.

The next components of a business architecture being discussed are principles and business domains. Interestingly, in doing technology architecture, I’ve worked with principles (technology-based, such as open-source vs. closed source, best of breed versus best fit, etc.) and technology domains. There’s really no difference in approach other than we’re now dealing with business principles (he gave the example of “No supplies will gain more than 5% of internal market share”) and business domains.

He’s now discussing roles that may be found in the BP & BA activities. There seems to be a strong correlation between BPI (Business Process Improvement) initiatives and Business Architecture. While he hasn’t come out and said that they are one and the same, it does make sense. If Business Architecture isn’t a once-and-done deal, then it makes sense that BPI is really just the continuous evolution of the Business Architecture.

Well that was fun! First off, kudos to Dr. Richard Soley from the SOA Consortium and Nick Gall from Gartner for getting us together and for doing an excellent job of moderating our panel. I really enjoyed the conversation and the answers from my fellow panelists, Bill Conroy, Global EA Executive for Bank of America, and Sam Vetto, Enterprise Architect for The Hartford Insurance Company. We covered a whole range of topics including governance, relationship between BPM and SOA, the relationship between information architecture and SOA, competency centers, funding SOA, and of course, the role of Enterprise Architecture in all of it. The topic of metrics came up frequently, just as with my previous panel. We certainly all agreed that EA has a role in all of this.

I’ve offered to address some of the questions that we didn’t get to in this blog, hopefully I’ll be able to coordinate with Gartner and make it happen. While you’ll only get my answer, one is better than none. If you attended the session, and have now found your way to my blog, please feel free to email me at todd at biske dot com or submit your questions via comments, and I’ll be happy to offer my thoughts. Also, I believe that this session will be available as a podcast in the future, so keep an eye out for it. I’ll be sure to link to it from here.

I’m now listening to Anne Lapkin discuss the strategy-driven enterprise. She first provided an example of an organization where there was in-fighting going on over who “owned” strategy between the portfolio management organization and the enterprise architecture organization. Both groups were trying to do the right thing, but there was a lot of wasted activity to mediate between these two organizations. The problem was that there was not one unified way of looking at the future state. She is advocating expressing the goals, principles, and relationships of a business, what she terms the Unified Enterprise Context, in a way that everyone will agree on. Interestingly, she tackled the question where an organizational has a collection of independent operating units by pointing out that in order to have a Unified Enterprise Context, you need to have a Unified Enterprise. That question was more indicative of a federated enterprise. If your enterprise is federated, each federated group should have its own Unified Enterprise Context, but there really isn’t one overarching context. Interestingly, I think this ties directly into Nick Gall’s keynote. The federated enterprise has a very small waistline, or area of commonality and generality, across their groups. Resist the urge the grow that waistline, and operate according to the federated model that the company has chosen.

The EA Summit has begun and Nick Gall is giving the opening keynote. He’s discussing a “middle-out” architecture style that “enables decentralized change through … minimal constraints.” He’s working hard to not digress into a REST discussion. 🙂 The visual metaphor is an hourglass, where there’s a small set of constraints in the middle that enables things to work, and things that grow outward in both directions. In the upward direction, it’s about the business. Many businesses can all be made to fit within these small constraints. Going down it is about the technology. Once again, there’s a multitude of technologies that can be made to fit those constraints. Many web servers all support the core web protocols.

Beyond the natural ties back to a REST approach, there’s a lot of truth to this metaphor. Both the business and the technology can be viewed as a hierarchical set of constraints. There are a small set of high level constraints that control everything that goes on underneath them. Architecture begins with these, and they are broadly applicable. Put too many of these things in the middle and, as Nick puts it, your waistline grows. If your waistline grows, things get more bloated, and you need more and management, process, etc. to ensure the adoption of these constraints and all of the exceptions associated with them. Doing income taxes comes to mind, for me. How many of the questions on my tax form are applicable to me? Having to go through the process of them makes things more complicated. Many things on the tax forms are so complicated that it’s difficult for an individual to know whether they even apply or not. At the opposite extreme, the narrowest of waistlines would be a standard flat tax. No exceptions, no complexity, just take 17% (or some other appropriate number) and give it to the government. Is there a need to distribute that tax to the local, regional, and federal agencies? Yes, but does that complexity need to be exposed to everyone in the middle? No, it doesn’t. Move it up/down in the hourglass to the areas that care about it, but don’t expose it generally to everyone.

If nothing else, Nick has certainly managed to get me noodling on this whole “narrow waistline” and hourglass approach. It’s a very interesting concept. The immediate concern that I have is that there’s a lot of changes that go on within the sands of the hourglass, and there’s a tendency for things to push toward the middle. To make this work, I think we’ll need appropriate guidance on how to maintain our perfect hourglass shape over time. I suggest using analogies of eating healthy and exercising frequently.