Only a very small percentage of the working population is evaluated by someone who shares their technical expertise. This site is full of questions from (for example) developers working in software development firms who are managed by people who don't understand the tools and languages the developers are using, because they have changed since the manager held the job. Your situation isn't that different.
So, you are never going to get "wow, this architectural solution for the new API is elegant and efficient!" as a review. (Or whatever applies to your skill set.) That's ok. You have four things you can do:
- know your value to the firm (based on its overall goals)
- get your technical strokes elsewhere
- get evaluated within the context of a team
- find some role models
To elaborate on each of these, say your firm makes and sells tires and you write software that helps with logistics - making sure rubber gets to the right factories, and tires get to the right warehouses. In one sense, it doesn't matter if your code is beautiful, or well-commented, or fast. As long as it's "good enough" and the rubber, tires, etc are in the right places, that's fine. But in the long term, of course, it matters that you are not piling up technical debt, that the software can be adjusted as the world changes, and so on. You need to keep the purpose of the software and the context in which it lives front of mind as you work. When you summarize your year for your boss, you need to pull out reminders - that time you were able to easily import the numbers for the warehouse that was acquired mid year, and everyone thought it would be a nightmare but it went fast and smooth? - that time management wanted those extra reports to handle some sort of scandal with a vendor and you were able to product them in a single day? as well as overall statements like the code is well maintained, you have a written list of procedures, it's possible for others to fill in for you because you share knowledge, and so on.
If you really need to hear that your technical chops are good (and you want to make sure that they are) then by all means join a user group, start contributing to open source, blog, tweet, write a library, deliver lunch and learns to other people in your firm who work in your noncore area, and so on. This kind of initiative is generally interpreted (by people who can't evaluate your technical skills) to mean you must have great skills, it will genuinely improve you, and it will put you in touch with people outside the firm who can give you some validation. Also, ask to attend specific conferences or to get specific training, to keep yourself up to date. Remember to phrase it in a way that makes sense to the business. ("When I joined, any time we had to exchange information with a partner it was SOAP and XML. Now it's REST and json and I need to make sure I'm using tools that let me get it done as quickly as possible and not do it all by hand."
If you are non core but not the sole person in your role, work with the rest of your team. Make sure the whole team understands they support the company, and understands that although logistics is kind of boring, and doesn't provide a lot of chances to code glowing jelly buttons or autofilling forms or to use the latest tech, when it fails everybody notices! If you make your team better (as a leader or from below) the higher ups will notice. Getting people to care about the noncore stuff they do can sometimes be a challenge, so once you start caring that the tires and the rubber are in the right place (or whatever) then it may well become infectious. On top of that, your team-mates can be a source of that technical improvement and validation.
Finally, do a little looking into your heroes. The lawyers, marketers, sys admins, programmers, or whatever whose blogs you read or whose courses you watch. Where do they work? Where did they work before they were full time experts? Find examples of people who you think are great who you can identify with. If you can't find any, then it's possible that in your field the very best always end up in firms that specialize in what they do. Should that be the case, then when you have risen and shone as much as you can where you are, you can think about being somewhere else. But not before.
One other thing to consider is just how noncore you are. If you clean the floors in a place that makes tires, sells insurance, invests money and so on then nobody cares how good you are. Nobody. As long as you are good enough, that's fine. If you come up with a technique that gets all the floors cleaned 10% faster, unless that enables laying off one floor cleaner, nobody cares, and possibly not even then if the floor cleaners are sort of low level security folks want around all the time. If you find a way to ensure no part of any floor is ever missed again, no-one will care. But if you work in a hospital they care. It's not core, cleaning the floors, but it's easy to relate excellence in cleanliness to the core values of the organization when it's a hospital instead of a generic office. Making software used by the core folks is closer to core than serving food in the cafeteria. Negotiating contracts for TV ads for tires is further from the core of a tire company than negotiating contracts for rubber. The further you are from the core the harder it is to connect true excellence (better than just ok) to success. So if it's important to you to pursue excellence and be rewarded for it, it is a good idea to evaluate the extent to which your excellence actually matters to anyone.