Innovation comes in all shapes and sizes. Business value, though, lies in translating ideas into production. We saw in our recent Innovation at Scale study that this translation, or "operationalizing analytics," remains one of the biggest challenges. I asked Shane, Principal Technical Architect, to share his views on the role of architects in guiding analytics-enabled innovation, the convenience of multisource tools and the importance of interoperability.
To get us started, please tell us how you came to be a software architect.
I've got quite a mixed bag of skills and experience: I’ve done some platform administration, I’ve implemented software architectures to match client environments, and I also enjoy teaching classroom-based technical skills at SAS. I'm currently certified to assess grid architectures and platform administrative processes as an enterprise architect. This is my ninth year in this role, and I'm loving every minute of it. Let’s cut straight to one of the main opportunities in technological innovation. We have quite a lot of customers looking to open source as a way to innovate.
What's your opinion of that?
Open source is very powerful and I think it has a real place in the market, but it's got to be managed correctly. Many companies make the mistake of not doing their homework properly, and then they realise they've got a problem further down the line. Open source products are great, but you do need to know what you are signing up for – have upfront guiding principles to help you make decisions around aspects such as whether you will continue to leverage the open version or close off a branch of the open source code for yourself, how to handle major changes in design direction from the open source community creators, or any security or legal constraints in merging proprietary and open source software. Finally, it’s essential to know whether you need enterprise-level support and if that support will be available within the open source community for the foreseeable future.
Do you think open source and proprietary software can co-exist comfortably?
Most definitely. You have to let people work with the tools that they like. If that means open source on top, and a proprietary solution underneath doing the number-crunching, then so be it. If manufacturers of proprietary software can deliver that kind of compatibility, then they broaden the scope for their products. It’s a win-win: Clients get to use the tools they like, and manufacturers get to sell reliable and high-quality software.
Do architects have a role in making that happen?
Again, very definitely. As an architect, I can see that companies want the quality of the analytics, like SAS can deliver, with all the patented algorithms built into the software. But they also want to use open source tools and maybe some tools from competitors – and that needs to be possible. If you have the right principles for the architecture, then it all works.
What architecture principles do you need to make these things coexist?
The most fundamental principle is that architects cannot live in a void! I have to be aware of what’s going on, including new technologies coming into the market, and then make sure that our proprietary software can fit into the client’s ecosystem. It’s not just a matter of co-existing: Our software needs to work well with open source so that we actually add value. It is therefore important to have a clear conceptual framework for the analytical capabilities or services required by the customer’s enterprise.
What do you think the role of an architect should be?
I've seen in numerous projects that the architect has to have a very broad understanding of all the technologies that are available. Even if you work for, say, SAS, clients will come to you and expect you know about all kinds of software, not just SAS. You need to be able to give them a way to integrate everything they want – effectively give them the information that they need to make a decision. It’s a bit like mediating between software options – you have to almost be neutral and just advise the client.
Have you ever had to make a comparison between new products and what we currently have?
Well, at the moment there's a big drive to get everything into the cloud. The challenge, though, is that cloud is not that simple. You've got numerous tied vendors, and you've also got a lot of people that want private clouds on-premises rather than using a public cloud. A number of our customers ask us to advise on whether to implement analytical capabilities on Microsoft Azure vs. Amazon AWS and within each option, whether to go with public or private cloud and what architectural limitations exist with regards to data movement costs, workload management and performance, to mention a few. As an architect, you need to know the differences and limitations of each option and try to guide the customer. It’s not always easy.
Do you find you have to balance the ‘now’ with future requirements?
Yes, very much so. We always try and work with the customer to make sure that we understand the long-term goal. Nobody wants to rework anything for no real reason. In a small percentage of cases, though, we may need to do a simple "lift and shift" to get them into the cloud environment quickly – but we'll always make clear that this is a short-term solution. In reality, we need to design for the end goal.
We have to be aware of what’s going on, including new technologies coming into the market, and then make sure that our proprietary software can fit into the client’s ecosystem. #innovation@scale Click To TweetThank you, Shane!
To learn more about how SAS is helping you gain greater business value by operationalizing your analytics, visit our site to see why data alone doesn't drive organizations: decisions do.
It is important to define the future-proof target architectures that are able to embrace and incorporate different technologies. SAS can conduct platform health reviews and analytics and model life cycle assessments to help you define an end-state vision architecture for your evolved analytics platform today.
