Wayne, John, Bryan, Cory, and I were on the server meeting. We went over a number of projects throughout the meeting. We need to spin up a couple more boxes and the guys were working on a quote and a time estimate for one of our clients. This was really cool, but Cory asked Wayne what it would take to get this project done. Wayne flipped it on its head and was talking about working the whole thing backwards. Basically, you start with what they want (that wasn't super clear) and then you figure out what things you will need to do to get there. Wayne's approach quickly started to focus on what was wanted vs what could we do (the sky is the limit). I've known that and even used it, but it was fun to see it play out in the meeting. I really enjoyed it.

We went over options and questions that we could take back to the client. Are they looking for access to raw data, summarized data, a webpage or web-based report, a spreadsheet, or even open API socket access points? That makes a huge difference as to where you go and what you do. We also talked about certain projects and possible code that has already been written for other clients and how we could tweak that if needed. Wayne was recommending that we get with the client, open up a blank spreadsheet and see what data they were looking for (basically doing some consulting - instead of just quoting something). I took it as a form of listening and even helping to educate our clients. That method or process, of talking with our clients, will actually help our clients be even more happy and really get what they want.

We have so many possible options, sometimes it takes some time to figure out what is really wanted and/or needed. There is a big difference between value and cost. We were talking about that. Ideally, we focus more on the value vs the costs. As we were talking about this, I was thinking about some of the ideas of the value add-on core model that we have been dreaming up for fracture. Here is a rough recap that I grabbed from an older element of time.

The concept of the value add-on core model - with different rings to denote the other levels of add-on value pieces. We have determined at least 5 levels as of right now. Starting from the middle. 1. Core (adilas core - everything that exists right now - image the), 2. Business vertical or industry specific, 3. Custom level, 4. BI or Business Intelligence level, and 5. Enterprise or multiple corp(s) level. Each of those value rings has to be purchased and serviced. You have to have the transactional data core to get it started, but anything beyond that, is extra or a value add-on piece. Very configurable.

Eventually, everyone will want some of the (BI) Business Intelligence stuff. This will take the underlying transactional data and will help to summarize it, aggregate it, count it, condense it, and display it in a way that is easy to digest and fun to look at (aka eye candy but also eye candy with a purpose). I'm really excited to get to that part of the project. I want to make sure, when we build out the fracture project, that we include this Business Intelligence (BI) level into the main application.

As far as history, when we started, we didn't have clear picture of where we were going. The further we go along the path, you can see how the other pieces play into the mix. I'm excited to keep working on them prior to getting to fracture, but I really want to make sure we include them in the next round. In a way, it's like what Wayne was saying, work the project backwards - what do you want, then make sure that it fits and fills those needs. Make the plan.